PDP2011 Serial Console Question

[Bill Backstrom]

FPGA newbie here. 

I'm trying to set up a DE0-CV with PDP2011. I've got the tool chain set up andrun through some tutorials and examples that came with the board.

I modified the de0cv/top.vhd to skip xu since I don't have an ethernet pmod. I think I've loaded the generated bit stream and the board passes the SD card detection test as described at https://pdp2011.sytse.net/wordpress/howto/first.

But here I'm stuck. I don't have a VGA monitor or PS/2 keyboard so I'm using a digilent RS232 pmod for serial console output but I'm not seeing any output on boot. My question is, do I need to configure something besides setting have_kl11 to non-zero to enable the serial port. Does the VGA console coexist with the serial console?

Hope this makes sense.

Thanks,

Bill

[Sytse van Slooten]

Hi Bill

the de0cv directory is set up to be used with a ps2 keyboard and vga screen as the console. There's some rudimentary definitions for a second port, but that's not the same thing - and yes those will 'coexist' doesn't mean it'll just work as you would hope, it's still two separate ports, and the console and the 1st serial are really different things for the OSes.

If you want the console to be somewhere else than on the ps2 keyboard and vga connectors, then you'll need to bring the rx and tx signals for the console port out to physical pins that you've connected the pmod to. Easiest is maybe to just remove all of the vt component instantiation, and change the instantiation of the unibus component to something like

tx0 => tx,

rx0 => rx,

so the console directly maps to those pins.

You'd have to figure out which pins those are - and maybe change them to something convenient on the 40-pin connectors on the board. It's a bit complex and daunting at first, but the flexibility of the fpga's, it'll grow on you ;-)

And let me know if you get stuck, or if you need help to figure something out. Happy to.

Cheers

Sytse

(oh btw I probably still have the issue that prevents me from mailing directly to gmail addresses, but works ok when I mail to googlegroups... sigh)

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/f64b9b32-5174-45a3-b092-af6513be18een%40googlegroups.com.

[Bill Backstrom]

Hi Sytse,

So I will need to move the pmod rx/tx pins from GPIO 1 pins 1 and 2 to a different set of pins for the console (plus make changes to the de0cv configuration)? Would comparing the unibus component for a board that does not use VGA/ps2 for the console be instructive? 

Also, led 7 on the board is on, does that mean anything? 

Thanks for your help.

Best Regards,

Bill

[Sytse van Slooten]

Something like that, yes - well, the gpio pins 1 1/2 should be fine, except...

I thought to find my de0cv and make a working config - but, I'm not sure why not, but I can't seem to get the bloody thing to work. Maybe it's the mess of wires on my desk, maybe it's the confusion of all versions of the core and the tool chain.

Led 7 (red, and counting from the right and starting from 0, and labeled something similar) should be ifetch - which is '1' whenever a new instruction is fetched; check line 725 in top.vhd. If lit, that kind of means the cpu is looping. It sort-of shows things are working as expected, except for the lack of console i/o, and something for the cpu to do - like booting an os, probably.

I'll get back on it tomorrow, not sure why it doesn't work for me now, but it has to be something obvious that I'm missing. Need to sleep now though.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/4e17e1f7-5748-49b2-b5f5-f5d58e97bf2an%40googlegroups.com.

[Bill Backstrom]

I didn't get to try any changes today. Not knowing any VHDL does not seem a plus so I started reading "Free Range VHDL". I did try copying RT-11 to an SD card and seeing if that caused any changes to the blinky lights but the card wasn't even detected so I must have missed something. I went back to reading after that ;)

[Sytse van Slooten]

Ok, I got it to work.

The mistake I made yesterday: I forgot that the pmodrs232 needs power - I only wired up the gnd signal, but it needs vcc too - obviously.

What you need to do to make it work with a serial port console instead of the default vga/ps2 internal console:

- comment out, or delete the vt instantiation (the line starting vt0: vt port map( until the closing parentheses)

- add two lines, on or about line 727 and similar to the lines already there, as follows:

tx <= txtx0;

rxrx0 <= rx;

- in the pdp2011 instantiation, change have_xu => 1 to have_xu => 0 ; if you don't connect the pmodnic100, you have to disable the xu core. You probably already did this, but to make sure.

Electrically, connect the pmod232 as follows:

pin 6 (vcc) to gpio1 pin 29 (count from the bottom and leave 5 open). 

pin 5 (gnd) to gpio1 pin 30

pin 4 (tx, from the fpga) to gpio1 pin 2

pin 3 (rx, from the fpga) to gpio1 pin 1

Refer to the de0cv user manual, figure 3-12 for the pin numbering ;-)

Cheers

Sytse

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/75580455-9640-47be-b07c-8a0b7c03aa04n%40googlegroups.com.

[Bill Backstrom]

That did it!

I had other issues on my side too. I have a breakout box between the pmod and my usb serial adapter. I didn't have all the necessary signals passed through and the adapter apparently requires RTS/DTS so those needed a jumper. 

More importantly, I had rx and tx from the pmod pins going straight to the rx and tx pins on the gpio rather than crossed over. Doh!

Many Thanks,

Bill

[Bill Backstrom]

Is there an alternative to the digilent pmod NIC100 ethernet module that is compatible with pdp2011? It seems to be discontinued and I can't find a source in the US that still offers it.

Thanks,

Bill

[Sytse van Slooten]

Basically anything with the same chip - enc424j600 - should work. But you'd probably find the same issue there - it's the chip that appears to be out of stock everywhere. And for instance Mouser lists a lead time of 90 weeks...

I was working on an alternative wifi frontend based on esp32, but I got stuck - the esp has some peculiarities that complicate the interactions, and the way I had in mind to deal with it didn't work very well so it seemed best to start from scratch. No big deal, it'll go faster with what I've learned, and at least I know that it is possible to make it work. I'll probably get back to it this fall/winter.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/5aeafdfd-c9bf-4914-99df-696c67e6388cn%40googlegroups.com.

[Jan Secker]

Trenz Elektronik in Germany has 6 pieces of these in stock. https://shop.trenz-electronic.de/en/search?sSearch=pmod+nic100

You could try ordering from them if shipping is not to expensive.

Jan Secker

Op vr 12 aug. 2022 om 13:12 schreef Sytse van Slooten <sy...@sytse.net>:

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/E1DE293D-46D7-4F83-9286-472F02FBD840%40sytse.net.

[Bill Backstrom]

Thanks. Unfortunately from Trenz with shipping it comes to about $90 to the US.

[Bill Backstrom]

Thanks, I will look around for an alternative. I might have seen something when I was searching but didn't pay attention to price or availability. The esp32 solution sounds really nice. I have an RS323 to wifi adapter for my telescope that uses an esp32.

In the mean time I'll look at slip, maybe add another serial pmod. 

I did find a VGA monitor at a thrift shop so I have the console running on it now and the serial port connected to rx2/tx2 so I can have two logins at once! I couldn't get rx1/tx1 to work, are they taken over by vt0?

[Sytse van Slooten]

On 12 Aug 2022, at 15:10, Bill Backstrom <home.ba...@gmail.com> wrote:

Thanks, I will look around for an alternative. I might have seen something when I was searching but didn't pay attention to price or availability. The esp32 solution sounds really nice. I have an RS323 to wifi adapter for my telescope that uses an esp32.

In the mean time I'll look at slip, maybe add another serial pmod. 

The bsd2.11 session on the website is about slip, maybe it'll be of some use. It worked nicely at that time, I haven't tried since though. Don't set the speed too high on the first attempts, that's one of the things I remember. 9600 is a good starting point - remember that was quite fast back in the day, and the cpu will still interrupt for each byte.

I did find a VGA monitor at a thrift shop so I have the console running on it now

cool ;-) 

for me it still works with all my monitors, even the newest one. As long as it has the db-whatsit connector. And from what I understand it should even be kind of trivial to get it to  work over hdmi, although I didn't really look into it yet. It's the ps/2 keyboards that are getting hard to find though, and I've never managed to get any usb-to-ps2 converters to work.

and the serial port connected to rx2/tx2 so I can have two logins at once!

huh? the sources I'm looking at don't have rx2/tx2 defined. It's easy enough to define them obvs ;-) 

I couldn't get rx1/tx1 to work, are they taken over by vt0?

but (continuing from above) there's two different aspects to the whole thing - providing the hardware, and letting the OS know about it and setting up for what to do with it. For most of the old OSes, ports beyond the console are not activated automatically - and they could be seen as terminals, printers, or other things we've forgotten about. So I'd guess that the vt0 thing could be something about the os configuration? 

Cheers

Sytse

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/50e6aec1-85e3-4eca-b12d-a118f27271edn%40googlegroups.com.

[Johnny Billquist]

On 2022-08-13 00:38, Sytse van Slooten wrote:
> for me it still works with all my monitors, even the newest one. As long
> as it has the db-whatsit connector.

DE15.

The nomenclature isn't that hard. It's Dxnn, where x gives the size of
the shell, and nn is the number of pins.

The standard PC serial port connector is then obviously DE9. The
standard 25-pin RS-232 connector is a DB25.

See https://en.wikipedia.org/wiki/D-subminiature for more details.

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Bill Backstrom]

I did find a VGA monitor at a thrift shop so I have the console running on it now

cool ;-) 

for me it still works with all my monitors, even the newest one. As long as it has the db-whatsit connector. And from what I understand it should even be kind of trivial to get it to  work over hdmi, although I didn't really look into it yet. It's the ps/2 keyboards that are getting hard to find though, and I've never managed to get any usb-to-ps2 converters to work.

 The shop where I got the monitor also had an old usb to ps/2 adapter, worked like a charm for me. I'll try a couple different keyboards and see if they also work.

and the serial port connected to rx2/tx2 so I can have two logins at once!

huh? the sources I'm looking at don't have rx2/tx2 defined. It's easy enough to define them obvs ;-) 

I was referring to the rx2/tx2 on the pin layout page (https://pdp2011.sytse.net/wordpress/wiring/), not the code. 

I couldn't get rx1/tx1 to work, are they taken over by vt0?

but (continuing from above) there's two different aspects to the whole thing - providing the hardware, and letting the OS know about it and setting up for what to do with it. For most of the old OSes, ports beyond the console are not activated automatically - and they could be seen as terminals, printers, or other things we've forgotten about. So I'd guess that the vt0 thing could be something about the os configuration? 

I don't think it is os related.  I have a RS232 breakout box with blinky lights on the side of the connector going to the terminal emulator. So the tx LED is the transmit from the "terminal" and the rx LED is the transmit from the de0cv.  When the board is reset or powers on, without booting any os, both LEDs are red (low) when running the bitstream without vt0. The console appears on the terminal emulator, both leds blink when there is traffic, all good. When using the bitstream that uses vt0 (and puts the console to VGA/PS/2) the rx LED (the tx from the de0cv) is solid green (high) and stays that way after booting unix.

These are the only changes from the distribution in this case. I tried have_kl11 => 2 also.

543c543

<       have_kl11 => 1,

---

>       have_kl11 => 4,

561c561

<       have_xu => 1,

---

>       have_xu => 0,

Booting 2.11BSD I get nothing on minicom unless I move the pmod from rx1/tx1 to the rx2/tx2 pins, then I get a login prompt, etc. I did update the kernel largely following the "PDP2011/FPGA newbie" conversation and various pages on your site. I haven't been down this road since messing with NetBSD on my Amiga and FreeBSD later on (I still have the CDs somewhere) but it started coming back.

[Sytse van Slooten]

On 13 Aug 2022, at 21:00, Bill Backstrom <home.ba...@gmail.com> wrote:

I did find a VGA monitor at a thrift shop so I have the console running on it now

cool ;-) 

for me it still works with all my monitors, even the newest one. As long as it has the db-whatsit connector. And from what I understand it should even be kind of trivial to get it to  work over hdmi, although I didn't really look into it yet. It's the ps/2 keyboards that are getting hard to find though, and I've never managed to get any usb-to-ps2 converters to work.

 The shop where I got the monitor also had an old usb to ps/2 adapter, worked like a charm for me. I'll try a couple different keyboards and see if they also work.

Ah ok cool - you wouldn't believe, but you're the first that positively reports getting this to work. As I said, I never managed. Might be due to the keyboards I have - a built-in hub is a definite no-no for this kind of thing, I believe

and the serial port connected to rx2/tx2 so I can have two logins at once!

huh? the sources I'm looking at don't have rx2/tx2 defined. It's easy enough to define them obvs ;-) 

I was referring to the rx2/tx2 on the pin layout page (https://pdp2011.sytse.net/wordpress/wiring/), not the code. 

Ah yes. The pin layout starts at 1, but the top.vhd source starts at 0.

In a bit more detail, the way the unibus.vhd component defines the serial ports, there is the kl0 component which creates the console serial port with CSR 17777560, and that comes out as the tx0 and rx0 signals. And the first non-console port, the kl1 component which has the CSR 17776500, and comes out as the tx1 and rx1 signals - provided you have the have_kl11 input variable set to something greater than 1. 

I couldn't get rx1/tx1 to work, are they taken over by vt0?

but (continuing from above) there's two different aspects to the whole thing - providing the hardware, and letting the OS know about it and setting up for what to do with it. For most of the old OSes, ports beyond the console are not activated automatically - and they could be seen as terminals, printers, or other things we've forgotten about. So I'd guess that the vt0 thing could be something about the os configuration? 

I don't think it is os related.  I have a RS232 breakout box with blinky lights on the side of the connector going to the terminal emulator. So the tx LED is the transmit from the "terminal" and the rx LED is the transmit from the de0cv.  When the board is reset or powers on, without booting any os, both LEDs are red (low) when running the bitstream without vt0. The console appears on the terminal emulator, both leds blink when there is traffic, all good. When using the bitstream that uses vt0 (and puts the console to VGA/PS/2) the rx LED (the tx from the de0cv) is solid green (high) and stays that way after booting unix.

Probably then the led isn't mapped to an active serial port line, I'd wager? 

These are the only changes from the distribution in this case. I tried have_kl11 => 2 also.

543c543

<       have_kl11 => 1,

---

>       have_kl11 => 4,

561c561

<       have_xu => 1,

---

>       have_xu => 0,

Booting 2.11BSD I get nothing on minicom unless I move the pmod from rx1/tx1 to the rx2/tx2 pins, then I get a login prompt, etc. I did update the kernel largely following the "PDP2011/FPGA newbie" conversation and various pages on your site. I haven't been down this road since messing with NetBSD on my Amiga and FreeBSD later on (I still have the CDs somewhere) but it started coming back.

this is where I get confused. 

There's nothing in the distribution for de0cv about pins named rx2/tx2, is there? or am I looking in the wrong place? Of course it's easy enough to add, but then I can't really comment on what is going on without having details.

And the second point, BSD as distributed normally only has the console - although if you use a starting point other than a distribution tape, something might already have been defined. 

To find out what's going on:

- if you get a prompt on the 2nd port, which device (line, /dev/xx) do you get into in BSD?

- what is the definition for that line in /etc/dtab?

- how do the signals for kl1, kl2, kl3 on the unibus component get mapped external to the fpga?

None of this is magic - but it can be very confusing and take a lot of time to sort out ;-)

Cheers

Sytse

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/4c061158-0cbb-4c3a-b994-e48bac0b0a55n%40googlegroups.com.

[Bill Backstrom]

I don't think it is os related.  I have a RS232 breakout box with blinky lights on the side of the connector going to the terminal emulator. So the tx LED is the transmit from the "terminal" and the rx LED is the transmit from the de0cv.  When the board is reset or powers on, without booting any os, both LEDs are red (low) when running the bitstream without vt0. The console appears on the terminal emulator, both leds blink when there is traffic, all good. When using the bitstream that uses vt0 (and puts the console to VGA/PS/2) the rx LED (the tx from the de0cv) is solid green (high) and stays that way after booting unix.

Probably then the led isn't mapped to an active serial port line, I'd wager? 

That is pretty much my original question. When the console goes to VGA/PS2 are pins 1 and 2 on gpio connector 1 still available to be used for a serial port? I think the gears are

starting to turn slowly in my head...

The console is always on the first kl11. In top.vhd that's associated with tx0/rx0. The pin assignment maps those to pins 1 and 2 on gpio 1, but those pins are not going to work as a serial port when vt0 is driving things. If I want to use those pins for a serial port I need to change which kl11 is assigned to those pins.

 

Does this make sense?

These are the only changes from the distribution in this case. I tried have_kl11 => 2 also.

543c543

<       have_kl11 => 1,

---

>       have_kl11 => 4,

561c561

<       have_xu => 1,

---

>       have_xu => 0,

Booting 2.11BSD I get nothing on minicom unless I move the pmod from rx1/tx1 to the rx2/tx2 pins, then I get a login prompt, etc. I did update the kernel largely following the "PDP2011/FPGA newbie" conversation and various pages on your site. I haven't been down this road since messing with NetBSD on my Amiga and FreeBSD later on (I still have the CDs somewhere) but it started coming back.

this is where I get confused. 

There's nothing in the distribution for de0cv about pins named rx2/tx2, is there? or am I looking in the wrong place? Of course it's easy enough to add, but then I can't really comment on what is going on without having details.

These were from your web site on the Wiring page of the blog (https://pdp2011.sytse.net/wordpress/wiring/) on March 19, 2019 not the distribution.  Sorry for the confusion.

And the second point, BSD as distributed normally only has the console - although if you use a starting point other than a distribution tape, something might already have been defined. 

To find out what's going on:

- if you get a prompt on the 2nd port, which device (line, /dev/xx) do you get into in BSD?

[30] root--> tty

/dev/ttyl1

 

- what is the definition for that line in /etc/dtab?

 

cn      1 176500 300    5       cnrint  cnxint  # kl/dl-11 (on mvx11-aa)
cn      2 176510 310    5       cnrint  cnxint  # another

I changed NKL to 4 in the sys/conf/PDP2011 and compiled the kernel.

 

- how do the signals for kl1, kl2, kl3 on the unibus component get mapped external to the fpga?

I haven't changed any of the pin assignments, just made the changes to de0cv/top.vhd to have_xu and have_kl11 and compiled in Quartus. 

None of this is magic - but it can be very confusing and take a lot of time to sort out ;-)

And has been a load of fun for me, thank you for all you help with this (and the project itself of course)! 

Thanks,

Bill

Cheers

Sytse

[Sytse van Slooten]

On 14 Aug 2022, at 18:11, Bill Backstrom <home.ba...@gmail.com> wrote:

I don't think it is os related.  I have a RS232 breakout box with blinky lights on the side of the connector going to the terminal emulator. So the tx LED is the transmit from the "terminal" and the rx LED is the transmit from the de0cv.  When the board is reset or powers on, without booting any os, both LEDs are red (low) when running the bitstream without vt0. The console appears on the terminal emulator, both leds blink when there is traffic, all good. When using the bitstream that uses vt0 (and puts the console to VGA/PS/2) the rx LED (the tx from the de0cv) is solid green (high) and stays that way after booting unix.

Probably then the led isn't mapped to an active serial port line, I'd wager? 

That is pretty much my original question. When the console goes to VGA/PS2 are pins 1 and 2 on gpio connector 1 still available to be used for a serial port? I think the gears are

starting to turn slowly in my head...

The console is always on the first kl11. In top.vhd that's associated with tx0/rx0. The pin assignment maps those to pins 1 and 2 on gpio 1, but those pins are not going to work as a serial port when vt0 is driving things. If I want to use those pins for a serial port I need to change which kl11 is assigned to those pins.

 

Does this make sense?

There's three things to keep in mind:

1) the serial ports are defined in the unibus component. So in the instantiation of that component (that's the bit where you set the have_kl11 to something) you also need to map the serial port signals (most important: rx and tx) to something outside. Think of the unibus component as a giant IC that needs to be hooked up to something, same as you would do if you were drawing a schematic or wiring up a PCB. Except it's in a weird language (it's actually possible to do it in a drawing as well, but it's so much work nobody does that for a real design).

What I usually do is map those rx and tx signals to intermediate signals. Why? because in that way, you can also copy those for leds etc - and one of the peculiarities of VHDL is that you can't copy things that are outputs. Using an intermediate signal is a bypass for that.

So in the instantiation of the unibus component, there are lines like:

tx0 => txtx0,

rx0 => rxrx0,

tx1 => txtx1,

rx1 => rxrx1,

etc - and obviously those need to be there for all the serial ports you want to enable. If you set have_kl11 => 4, then 0 upto 3 for the tx and rx need to be defined. And the signals need to be declared as well:

signal txtx0 : std_logic;

etc etc.

2) The intermediate signals from above need to be connected (copied) to the pins that are defined for the top component - the thing that the top.vhd starts with, and the input and output definitions on there. Or to something more complex in between, like the vt. I think in the last distributed version, I do the copying to the vt component directly, as in there's a bit like

rx => txtx0,

tx => rxrx0,

in the vt component instantiation.

A similar analogy applies here too - if you consider the vt component as a chip, we're just wiring it up, connecting it to the other components.

The same thing for the ports that'll be outside the fpga is the part that goes like

tx1 (ie, the outside port name) <= txtx1; (the inside signal name)

rxrx1 <= rx1; (and note here the direction of the copy... again, vhdl won't allow you to copy something defined as an output)

3) the port signals defined on the top entity (ie, what connects to outside the fpga) are, as I said, defined at the start of the source file (the bit that goes 'entity top'...

Those are also usually called 'pins'. Where on the FPGA they appear is defined in the top.qsf file - you can edit it by hand, or use a Quartus component called pin planner. 

That's where the pins on the top of the gpio connector come in.

you're not limited to the gpio1, of course - you can also use the gpio0, there are some leftover debug pins in de de0cv project files, but nothing essential. And the same for gpio1 really - most of the pins there are for the pidp11 panel, but there's also the sd card pins that you probably don't use. And if you don't have the panel, you could reassign those as well.

These are the only changes from the distribution in this case. I tried have_kl11 => 2 also.

543c543

<       have_kl11 => 1,

---

>       have_kl11 => 4,

561c561

<       have_xu => 1,

---

>       have_xu => 0,

Booting 2.11BSD I get nothing on minicom unless I move the pmod from rx1/tx1 to the rx2/tx2 pins, then I get a login prompt, etc. I did update the kernel largely following the "PDP2011/FPGA newbie" conversation and various pages on your site. I haven't been down this road since messing with NetBSD on my Amiga and FreeBSD later on (I still have the CDs somewhere) but it started coming back.

this is where I get confused. 

There's nothing in the distribution for de0cv about pins named rx2/tx2, is there? or am I looking in the wrong place? Of course it's easy enough to add, but then I can't really comment on what is going on without having details.

These were from your web site on the Wiring page of the blog (https://pdp2011.sytse.net/wordpress/wiring/) on March 19, 2019 not the distribution.  Sorry for the confusion.

And the second point, BSD as distributed normally only has the console - although if you use a starting point other than a distribution tape, something might already have been defined. 

To find out what's going on:

- if you get a prompt on the 2nd port, which device (line, /dev/xx) do you get into in BSD?

[30] root--> tty

/dev/ttyl1

yes, that'd be the 176500 port, normally

 

- what is the definition for that line in /etc/dtab?

 

cn      1 176500 300    5       cnrint  cnxint  # kl/dl-11 (on mvx11-aa)
cn      2 176510 310    5       cnrint  cnxint  # another

ok - the cn2 would become the 3rd port, and need something in /etc/ttys as well I believe

I changed NKL to 4 in the sys/conf/PDP2011 and compiled the kernel.

ok - that'd give you 4 ports, so you'd need another cn line in /etc/dtab, and the same about /etc/ttys.

 

- how do the signals for kl1, kl2, kl3 on the unibus component get mapped external to the fpga?

I haven't changed any of the pin assignments, just made the changes to de0cv/top.vhd to have_xu and have_kl11 and compiled in Quartus. 

ok, so that's what's missing. Hope the whole text that I started with clarifies that? let me know if I missed something.

None of this is magic - but it can be very confusing and take a lot of time to sort out ;-)

And has been a load of fun for me, thank you for all you help with this (and the project itself of course)! 

hehe yes you're welcome! it's still something like magic to me, after all this time I'm still amazed that I got it to work - and also that it's so stable. My own bsd system regularly gets up to more than 100 days uptime, and usually it is a power issue that brings it down.

Thanks,

Bill

Cheers

Sytse

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/80d5ea3a-1899-4961-8d36-50fb8d7bb9a5n%40googlegroups.com.

[richard...@gmail.com]

Seeing this thread reminded me to update my own pidp2011 fpga system to use the latest offering of updates. Doing this has been made difficult by the larger size of the resulting  FPGA bitstream on my system and I have had to ditch the VGA section and switch to having a serial consoles only. Previously I had VGA and two serial devices with a login on all three. However things are behaving very odd now and although its late now I think I'm just starting to understand something about the problem.  I have some BSD2..11 sdcard images which allow serial login and others which do not. console login is always ok. Some of my old systems sdcard images have two extra serial logins and these work. The ones with just a single extra login do not work. all with the same FPGA bitstream. Ive seen a similar problem described here: https://forum.vcfed.org/index.php?threads/finding-my-serial-ports-in-bsd-2-11.46773/ 

Quote:

```As far as I can tell there is a bug in cnattach (rookie <= error where it should use <) which would allow an attach for 1 unit larger than was configured (possibly corrupting kernel memory), but then cnopen would correctly fail the open if the unit number is too large. If you are actually running with a kernel where cons.c was built with a NKL value of 1, that might explain why this attach worked succeeded:
cn 1 csr 176500 vector 300 attached

But then the open/create of /dev/ttyl1 failed.``` 

My version of cons.c appears to have the problem code, it this really a bug or what?

I'll investigate this some more tomorrow,  David.

[Bill Backstrom]

What timing.  I managed to corrupt my sdcard so I decided to start fresh and copied Sytse's 2.11BSD image to a new sdcard, made all the changes (I think) that I had done previously to get a VGA console and one serial port login working. Now however I get what you were seeing in your thread:

cn 1 csr 176500 vector 300 attached

cn 2 csr 176510 vector 310 attach failed

I did NOT do a 'make clean; make' after changing NKL, just a plain make. I will try that as soon as I can get back in front of the keyboard.

[Bill Backstrom]

A 'make clean' after changing NKL did it for me. I made the change and did the build under simh but it booted fine under PDP2011 and I have my serial port back.

[richard...@gmail.com]

Hi Bill, yes I had not realized that the default image on the new card image did not have NKL set above 1 when I tried to access the second port. rebuild with NKL set too 2 made my system now works with the second login prompt working. Rebuild on the target system took a while but got there in the end with the Makefile edited to move the toy object. False alarm over. I would like to try to build some of the minc peripherals soon but first I need to reconfigure my networking. David.