> -Original Message-
>
> ESC D and ESC M scroll the screen. The problem is that most "ANSI"
> implementations don't implement the full VT-100 command set, so that one
> may not be supported on most terminal emulators.
You know what... my faulty memory got me again. I was remembering
>From what I could find a real vt100 has scroll up and down.
-- John.
yah thats right, you just have to remove the hooks. you should be good.
Anyways I am working hard on a "REX integration" solution for VT100. it is
coming along but debug can take a long long time.
On Mon, Dec 21, 2020 at 11:03 PM Jim Anderson wrote:
> > -Original Message-
> >
> > Jim,
> -Original Message-
>
> Jim, you are not trying to use VT100.CO with REX are you? They are
> not compatible. ..Steve
I'm using it in a machine which has a REXCPM in it, but I unload the REX hooks
with Ctrl-X and power-cycle before invoking VT100.CO - this always worked with
the
> -Original Message-
>
> Exactly. I had to add custom vt100 commands to thr vt100 terminal
> firmware.. I just did it wrong.
Well, I don't know about 'wrong' if the M100 OS expects the display device to
have an ability the VT100 doesn't provide...
> Anyone can jump in and fix it if
See, that is what I have been saying: if Virtual T does not behave like a
real one, it is not doing its job.
On Mon, 21 Dec 2020 at 04:07, Stephen Adolph wrote:
> Ok thanks for the info. I did it quickly, assuming that what was working
> in virtualt would also work in reality.
>
> Not always
Hi again — as a quick follow-up, I was able to convert these four chip extracts
from HEX into BX. I then tested them by loading 'em into REX, so they should be
in good shape.
disk31.hex and .bx … Disk+ (aka Disk 4) ver 3.1
gold71.hex and .bx … appears to be a custom ROM with “Gold” written in
Jim, you are not trying to use VT100.CO with REX are you? They are not
compatible. ..Steve
On Mon, Dec 21, 2020 at 7:07 AM Stephen Adolph wrote:
> Ok thanks for the info. I did it quickly, assuming that what was working
> in virtualt would also work in reality.
>
> Not always the case.
>
> I
Sure send the RAM image. I'll check it out in Virtual T (the prototype
that I have that supports REX# and REXCPM- hopefully that will get released
at some point. As is par for the course with me, I introduced a bug or 2
into the prototype but heck it was my first ever C programming).
On Mon,
Exactly. I had to add custom vt100 commands to thr vt100 terminal
firmware.. I just did it wrong.
Anyone can jump in and fix it if they want. Don't wait for me.
In fact I would prefer if someone decides to pitch in and help.
I have posted the files. It is C. The tools are downloadable.
Ok thanks for the info. I did it quickly, assuming that what was working
in virtualt would also work in reality.
Not always the case.
I noticed that last night that the VT100 driver embedded in rex# also has a
bug.
I'll take it down. I'm sure when I find the issue on REX# it will be
apparent
> -Original Message-
>
> Active block is always first, does seem to fit what is happening? I just
> checked on my end and it seems to be working. Active block first, then
> sorted by date/time.
Yes, it shows the active block first as always, it's the rest of the entries
which aren't
> -Original Message-
>
> Updated to build 21, with a bug fixed.
> Please report any issues, thanks!
I tried this out tonight after I finished restoring everything to my other
REX...
I didn't have much success with it - it does initialize, but after going into
BASIC and issuing either
13 matches
Mail list logo
