long lines of text over serial issue

[nippur72]

I have an issue when sending long lines of basic text from the serial port.

When I send more than 90 characters without a carriage return, the LM80C displays spaces and starts to behave erratically. See the right picture, it's the result of sending:

12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890

Short lines are ok, indeed nothing is missed as shown in the left picture. It's a basic program sent as a big string, the only difference is that it contains carriage returns. 44850 is the sum of all integers from 1 to 299 -- that's how I make sure nothing was missed).

Can you please verify on the real LM80C? I tried my best to make sure it's not an emulator issue, sorry in advance if it's so. Using latest r39. I'm trying to paste a long basic listing adapted from another machine.

[leomil72]

The line buffer is 88 chars longs so the risk that something isn't running properly is high. Sincerely I didn't put a lot of efforts on the serial management. I will try o. The real HW ASAP.

[leomil72]

I've started looking at this issue right now and I read again your notes. I noticed this:

I'm trying to paste a long basic listing adapted from another machine.

I can affirm that there is no problem doing this, in fact I myself use the serial to "load/save" big programs, too. The only limit is, as I already said before, the buffer size: if a line is longer than the size of the input buffer, the interpreter should close the serial line to stop receiving further chars. Because it can't manage them. If you import through the serial lists from other Basic dialects you have to check that each line won't be longer than 88 chars (to be more precise, 87 chars since you need to consider the "null" char at the end of the line). If a line is longer, split it into 2 shorter lines. So I did for several programs. PS: at the moment the interpreter is going crazy just because there is surely some bug into the code but long lines are to be avoided, anyway.

[nippur72]

I agree lines must be as short as possibile, but long lines was very common back in the days because it made programs faster (less line numbers to process during GOTOs) and because it was useful in IF THEN statements to compensate the lack of ENDIF.

If I've got it correctly, this limitation is because characters, either typed directly or coming from the serial line, are put in the serial buffer which acts as the "edit buffer" for the NASCOM Basic. Is that so?

Ideally the edit buffer should be the video memory itself, allowing lines as long as there is space. On the other side, the keyboard buffer could be much smaller. For example the VIC-20 had a 255 line length and a 16 character keyboard buffer. And the 255 limit was imposed only by tokenizer routine that used the X register to index across the line.

But I guess it's hard work because the whole editing routine has to be rewritten. So why not just extend the buffer to 255 for now?

My concern about the limited line length is that it makes porting existing BASIC listings a tedious work. For example I was converting a text adventure game, but over 40% of the lines are longer than 88 chars, like this one:

92 on lo gosub 2000,2010,2020,2030,2040,2050,2060,2070,2080,2090,2100,2110,2120,2130,2140,2150,2160,2170,2180,2190,2200

...just not worth the effort.

[leomil72]

I know there are systems that had a different way of working but when I adapted the NASCOM Basic to my needs I did some compromises. Originally, the NASCOM Basic was a terminal-only interpreter with a 64 chars serial/input buffer and a 72 chars tokenizer buffer. When I created the video interface I needed a way to pass what was typed on the keyboard to the interpreter and I decided to follow the easiest way: put everything in the input buffer as it was originally received through the serial. Also, this made things easier to continue to receive data from the serial since there was only an input buffer. The down side was that I had 2 buffers: when chars arrived from the serial they were parked into a separated buffer (the serial buffer) and then copied into the tokenizer buffer, from where the tokenizer gets the direct commands and program lines, and analyze & execute them. I expanded both buffers to 88 chars, a good compromise between size and line length. Not every system had large buffers, my C16 had something around 72/80 chars, no more. If I encounter long lines I splitted them with an "IF" before the ON..GOSUB. Moreover, I wouldn't expand the buffers because I wouldn't break the psycological wall of the "32000 bytes free". But feel free to modify the source code to get the size you need