search

rcornwell / sims

Burroughs B5500, ICL1900, SEL32, IBM 360/370, IBM 7000 and DEC PDP10 KA10/KI10/KL10/KS10, PDP6 simulators for SimH
http://sky-visions.com
95 stars 20 forks source link

KA10: Terminal multiplexers should not write to txdone #153

Closed larsbrinkhoff closed 5 years ago

larsbrinkhoff commented 5 years ago

@markpizz pointed out txdone is private to TMXR.

larsbrinkhoff commented 5 years ago

Also don't set UNIT_DISABLE.

larsbrinkhoff commented 5 years ago

Also check why DPK only allows one connection.

larsbrinkhoff commented 5 years ago

Also this:

In order for the TMXR layer to know about which units manage which lines, the device reset routine should call:

t_stat tmxr_set_line_unit (TMXR mp, int line, UNIT uptr_poll); t_stat tmxr_set_line_output_unit (TMXR mp, int line, UNIT uptr_poll);

larsbrinkhoff commented 5 years ago

I made the requested fixes to the MTY device. It seems to work exactly like before, no better or no worse. Still sluggish compared to using sim_activate.

larsbrinkhoff commented 5 years ago

The changes are on my branch here:
https://github.com/larsbrinkhoff/ka10-simh/commits/lars/tmxr

rcornwell commented 5 years ago

If this works, push it to the repo. I am planing on pushing the current system to the main simH tree within the next day or two.

larsbrinkhoff commented 5 years ago

I'll try. If I miss the window, no big deal.

larsbrinkhoff commented 5 years ago

I posted a pull request: #159. I still have to fix DPK to allow more than one connection.

larsbrinkhoff commented 5 years ago

Based on input from @markpizz, I'm reconsidering the implementation of MTY. The other two, TK10 and DPK should be OK.

I'm thinking something along the line of two UNITs for the DEVICE. One unit polls for connections and input. The other is for output. The output unit should keep track of one word being output for each line, and feed data one character at a time to tmxr_putc_ln.

larsbrinkhoff commented 5 years ago

Oh, and the output unit could schedule with sim_activate for speedy service, in case sim_clock_coschedule remains sluggish. It need not be active when all lines are idle.

larsbrinkhoff commented 5 years ago

I'll close this one, because the txdone thing has been fixed.

markpizz commented 5 years ago

I'm thinking something along the line of two UNITs for the DEVICE. One unit polls for connections and input. The other is for output. The output unit should keep track of one word being output for each line, and feed data one character at a time to tmxr_putc_ln.

That would be fine. It should be scheduled from DATAO with sim_activate_abs(&unit[1], 0) whenever data is being presented for transmission.

When you do this, don't forget to change the value specified in tmxr_set_line_output_unit() to the second unit for each line.

Oh, and the output unit could schedule with sim_activate for speedy service, in case sim_clock_coschedule remains sluggish.

If you actually want precise timing to reflect the selected line speed across all lines that may be active at the same time, then essentially any sim_activate or sim_coschedule form should be used AS LONG AS you specify a sufficiently long activation interval (100ms will work well with idling). The tmxr internal logic will shorten your supplied activation time as needed to achieve the specified output rates.

It need not be active when all lines are idle.

True, but figuring out that detail may be more complicated than just scheduling a long poll and letting the internal logic work.

larsbrinkhoff commented 5 years ago

True, but figuring out that detail may be more complicated than just scheduling a long poll and letting the internal logic work.

I'll try that. But so far my experience has been that using sim_activate will not let the device idle properly. And sim_clock_coschedule makes it slow. So as a workaround, I'm prepared to add a sim_cancel when all lines are idle.