Re: [Freedos-user] A few suggestions to improve debug

2020-09-02 Thread dmccunney
On Wed, Sep 2, 2020 at 5:47 AM tom ehlert wrote: > > UNIX System V certainly was connected to serial terminals (Televideo, > VT100, ...) > > and it had the VI visual editor with definitively cursor movement > across the screen, even when the terminal had no cursor keys. I was a system

Re: [Freedos-user] A few suggestions to improve debug

2020-09-02 Thread Ralf Quint
On 9/2/2020 2:29 AM, tom ehlert wrote: UNIX System V certainly was connected to serial terminals (Televideo, VT100, ...) and it had the VI visual editor with definitively cursor movement across the screen, even when the terminal had no cursor keys. cursor movement is not tied to memory-mapped

Re: [Freedos-user] A few suggestions to improve debug

2020-09-02 Thread tom ehlert
> And as there aren't many tools where ZB's idea would make > sense in his opinion, it seems a bit like brewing up a tempest in a > teacup... ;-) +1 > And another reason why this might not be in general a good idea is if we > take compatibility with old(er) DOS software/environments serious,

Re: [Freedos-user] A few suggestions to improve debug

2020-09-01 Thread Ralf Quint
On 8/31/2020 7:16 PM, Jon Brase wrote: > Not that convincing rationale considering rather modest overhead necessary. Recall that FreeDOS isn't just about having a FOSS alternative to MS-DOS for modern machines (where you're really better off just using Linux and DOSBox), or for your

Re: [Freedos-user] A few suggestions to improve debug

2020-09-01 Thread Bret Johnson
> I'm not sure, but probably a program can distinguish whether it's in > "interactive mode" or used for batch processing? It seems like this should be > possible, but I don't think it is. I've tried doing something similar > (though not quite the same), where I tried to automatically detect

Re: [Freedos-user] A few suggestions to improve debug

2020-09-01 Thread dmccunney
On Tue, Sep 1, 2020 at 1:35 AM Jon Brase wrote: > > > Not that convincing rationale considering rather modest overhead necessary. > > Recall that FreeDOS isn't just about having a FOSS alternative to MS-DOS for > modern machines (where you're really better off just using Linux and DOSBox), > or

Re: [Freedos-user] A few suggestions to improve debug

2020-09-01 Thread ZB
On Mon, Aug 31, 2020 at 09:16:54PM -0500, Jon Brase wrote: > Recall that FreeDOS isn't just about having a FOSS alternative to MS-DOS > for modern machines (where you're really better off just using Linux and > DOSBox), or for your early-90s 486 retrogaming machine, it's also meant > to be an

Re: [Freedos-user] A few suggestions to improve debug

2020-09-01 Thread Mateusz Viste
On 01/09/2020 04:16, Jon Brase wrote: it's also meant to be an alternative to MS-DOS for the very oldest PC hardware, all the way back to the original IBM 5150. The core software might therefore be expected to work in very little RAM. As I recall, the minimum configuration for the 5150 had

Re: [Freedos-user] A few suggestions to improve debug

2020-08-31 Thread Jon Brase
> Not that convincing rationale considering rather modest overhead necessary. Recall that FreeDOS isn't just about having a FOSS alternative to MS-DOS for modern machines (where you're really better off just using Linux and DOSBox), or for your early-90s 486 retrogaming machine, it's also

Re: [Freedos-user] A few suggestions to improve debug

2020-08-31 Thread dmccunney
On Mon, Aug 31, 2020 at 8:43 PM ZB wrote: > On Mon, Aug 31, 2020 at 05:07:14PM -0400, dmccunney wrote: > > > One of the most popular was Chris Dunford's CED. The following from > > the CED docs is relevant: > > Thanks, I'll try to examine it. Still my suggestion is to make all these > tools of

Re: [Freedos-user] A few suggestions to improve debug

2020-08-31 Thread ZB
On Mon, Aug 31, 2020 at 05:07:14PM -0400, dmccunney wrote: > One of the most popular was Chris Dunford's CED. The following from > the CED docs is relevant: Thanks, I'll try to examine it. Still my suggestion is to make all these tools of FreeDOS, that offer command line - better. There's

Re: [Freedos-user] A few suggestions to improve debug

2020-08-31 Thread dmccunney
On Mon, Aug 31, 2020 at 3:47 PM ZB wrote: <...> Recall that in the old days, DOS *COMMAND.COM* did not have command line recall and edito\ing. To get it, you installed a TSR that added it. There were a number of them. One of the most popular was Chris Dunford's CED. The following from the

Re: [Freedos-user] A few suggestions to improve debug

2020-08-31 Thread ZB
On Mon, Aug 31, 2020 at 12:40:34PM -0700, Ralf Quint wrote: > If you are trying to keep 20 lines in the "history" and even assuming you > limit the length of an entry line to 40 characters, that's already 800 > bytes, just for the buffer space... ...IN RAM, not in program code. :) > But in any

Re: [Freedos-user] A few suggestions to improve debug

2020-08-31 Thread Ralf Quint
On 8/31/2020 11:28 AM, ZB wrote: On Mon, Aug 31, 2020 at 11:10:56AM -0700, Ralf Quint wrote: On 8/31/2020 10:44 AM, ZB wrote: ... 2. It could keep "history" for last, say. twenty-thirty command-line entries (available as usual with Up/Down keys). ... A second issue is that a lot of

Re: [Freedos-user] A few suggestions to improve debug

2020-08-31 Thread ZB
One more I'm less interested in, but maybe it would be useful for the others? I mean assuming we have full control over cursor movement as already described - the "Ins" key could be a switch between default "insert" and alternative "overwrite" mode (if not too complicated to implement) --

Re: [Freedos-user] A few suggestions to improve debug

2020-08-31 Thread ZB
On Mon, Aug 31, 2020 at 08:11:48PM +0200, Eric Auer wrote: > Mercury also suggests Ctrl-Arrow for word-wise cursor movements. Alternatively we could use PgUp/PgDn for this, which aren't used (and probably won't be used for anything) by debug. This could have advantage of "Control" not being

Re: [Freedos-user] A few suggestions to improve debug

2020-08-31 Thread ZB
On Mon, Aug 31, 2020 at 08:11:48PM +0200, Eric Auer wrote: > It can harm if you do batch processing. And WHY do you perform "r" > at the start? I always only look at "r" AFTER doing things which > will have sent interesting data to the registers, NOT before. Just realized it's an old habit :D if

Re: [Freedos-user] A few suggestions to improve debug

2020-08-31 Thread ZB
On Mon, Aug 31, 2020 at 11:10:56AM -0700, Ralf Quint wrote: > On 8/31/2020 10:44 AM, ZB wrote: > > 1. I believe it would be handy if it could immediately after its start > >perform 'r' (show registers' contents). Usually we're going to have > >a look at that first when using "debug". Even

Re: [Freedos-user] A few suggestions to improve debug

2020-08-31 Thread ZB
On Mon, Aug 31, 2020 at 08:11:48PM +0200, Eric Auer wrote: > Hi ZB, > > > 1. I believe it would be handy if it could immediately after its start > > perform 'r' (show registers' contents). Usually we're going to have > > a look at that first when using "debug". Even if we aren't - having > >

Re: [Freedos-user] A few suggestions to improve debug

2020-08-31 Thread Eric Auer
Hi ZB, > 1. I believe it would be handy if it could immediately after its start > perform 'r' (show registers' contents). Usually we're going to have > a look at that first when using "debug". Even if we aren't - having > these two lines on the screen immediately after start won't do any

Re: [Freedos-user] A few suggestions to improve debug

2020-08-31 Thread Ralf Quint
On 8/31/2020 10:44 AM, ZB wrote: 1. I believe it would be handy if it could immediately after its start perform 'r' (show registers' contents). Usually we're going to have a look at that first when using "debug". Even if we aren't - having these two lines on the screen immediately after

Re: [Freedos-user] A few suggestions to improve debug

2020-08-31 Thread Mercury Thirteen via Freedos-user
4. Ctrl + Arrow should skip a word at a time, as in most modern text editors. Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Monday, August 31, 2020 1:44 PM, ZB wrote: > 1. I believe it would be handy if it could immediately after its start > perform 'r' (show