Anyone building a PICL? more PCBs available

[DavidMS]

My error I meant I was using 'send' rather than 'transfer'.

But anyway still nothing working I have attached screen shots of the what gets displayed and the copy buffer etc . The delay is set to 3/300ms I don't think I have changed anything else other than enabling local echo. It looks like it is just not waiting at the end of the line long enough for NIBL to process the line but extending the time does not seem to have any affect ?

I am sure it is something obvious on com port

[Phil__G]

Heres my setup, its running a NIBL prog on a PICL right now:
Try 'auto' on receive, the first screen looks like Teraterm isnt doing a linefeed after carriage return

[ortek_service]

Originally Posted by Phil__G

Heres my setup, its running a NIBL prog on a PICL right now:
Try 'auto' on receive, the first screen looks like Teraterm isnt doing a linefeed after carriage return

Yes. I've also set this to 'LF', to avoid the diagonal line of '>' prompts
- As it seems NIBL only sends 'LF', without a 'CR', so get this effect on most Terminal Programs I tried, without altering this setting.

Although I'm not sure if it would affect the 'Send', if that is purely transmitting without waiting for any response.
I've not tried sending a BASIC program into NIBL yet - Only using the Hexloader function, to upload m/c for running in Kitbug+.
But I'll give it a try, to see what happens on my setup
- I wonder if whether it works properly, depends on whether the file you send has CR, LF or CR+LF at the end of each line?

[Phil__G]

Both NIBL and KitbugPlus send CR and LF at every line end David. Can you manually enter a NIBL program, list it & run it?
Does the KB+ 'D' command display properly?

[Phil__G]

This is the only demo I have where you can see an upload:
https://youtu.be/sQQYscBaKGM

I've been playing with the Grant Searle Z80s for so long I'd forgotten how NIBL responds, I think your first screen shot is ok,
because of the local echo, when you send a file it appears immediately on screen, but actually sends slowly to the PICL,
and you see the prompts coming back from NIBL separately below.
If you have receive set to CR all the pasted text will be on one line, long lines overwriting short ones, and the prompts will move diagonally across the screen,
like the in video above.
Set receive to auto and it scrolls the pasted text correctly, then responds with all the prompts vertically - which I prefer
None of this affects loading, it looks weird on the screen but its caused by the local echo - ignore how it looks, the program loads fine!
Cheers
Phil

Try the attachment

[Phil__G]

Missed the edit window

This is the only demo I have where you can see an upload:
https://youtu.be/sQQYscBaKGM

I've been playing with the Grant Searle Z80s for so long I'd forgotten how NIBL responds, I think your first screen shot is ok,
because of the local echo, when you send a file it appears immediately on screen, but actually sends slowly to the PICL,
and you see the prompts coming back from NIBL separately below.
If you have receive set to CR all the pasted text will be on one line, long lines overwriting short ones, and the prompts will move diagonally across the screen,
like the in video above.
Set receive to auto and it scrolls the pasted text correctly, then responds with all the prompts vertically - which I prefer
None of this affects loading, it looks weird on the screen but its caused by the local echo - ignore how it looks, the program loads fine!

The same happens when hexloading except of course you dont see prompts coming back after every line,
you just have to wait until eventually it does prompt, and the serial I/O LED stops flashing.
I hadnt remembered this because for hexloading I use zero delays.

Cheers
Phil

PS Try the attachments above, all should work fine

[ortek_service]

Thanks for the example BASIC Program files nibl_progs.zip attachment.
- Saved having to type some into an editor, and worry about whether 'PC' format CR+LF, of 'Unix' format without the 'LF' was required.

I just sent Karen.BAS, using 5ms / 300ms delay in TeraTerm (4.106), and that all worked OK for me, running without any issues.

Originally Posted by Phil__G

Both NIBL and KitbugPlus send CR and LF at every line end David. Can you manually enter a NIBL program, list it & run it?
Does the KB+ 'D' command display properly?

Using RealTerm, to display incoming characters in Hex (In ASCII mode, it also shows special characters like CR / LF with CR / LF symbols), I found:

KitBug+ sends 0A 3F(=?) 0D 0A 0D 0A before sending the 'Kitbug+ > ' text to show its prompt, when Enter key is pressed on the terminal.

But NIBL only sends 0A 3E (The '>' prompt), in response to 'Enter' and so NIBL is not sending a 'CR' in response - Hence the diagonal line of '>', unless terminal program adds a C'R'.

However, if your type 'LIST' in NIBL,it does then send 0D 0A 0D 0A 3E (='>'), and so do get an extra blank line after listing, as well as a proper return onto next line (without requiring terminal program to do this).
I assume the PIC16F877 versions of NIBL behaves the same as this PIC16F18877 one?

[Phil__G]

Originally Posted by ortek_service

KitBug+ sends 0A 3F(=?) 0D 0A 0D 0A before sending the 'Kitbug+ > ' text to show its prompt, when Enter key is pressed on the terminal.

KitbugPlus responds to an input error or invalid command by attempting to put a '?' under the error using linefeed, and just pressing enter is an invalid command - so what you've seen is right Owen

[DavidMS]

Originally Posted by Phil__G

Both NIBL and KitbugPlus send CR and LF at every line end David. Can you manually enter a NIBL program, list it & run it?
Does the KB+ 'D' command display properly?

Phil - yes to both questions

[DavidMS]

Originally Posted by Phil__G

Set receive to auto and it scrolls the pasted text correctly, then responds with all the prompts vertically - which I prefer
None of this affects loading, it looks weird on the screen but its caused by the local echo - ignore how it looks, the program loads fine!

The same happens when hexloading except of course you dont see prompts coming back after every line,
you just have to wait until eventually it does prompt, and the serial I/O LED stops flashing.
I hadnt remembered this because for hexloading I use zero delays.

Phil, right I get it now. I had been working on the assumption the local echo would display a line send it, wait, then repeat for the next line. Rather it does all the local echo while buffering the data and sending it with the delay as set. Hence the screen looks like it is all messing up. Anyway as you can see in the attached screen shot I managed to load a relatively long program (first time) with your settings 5/300 and auto (receive).

Thanks for the help on this, now I just need to find a nice transparent topped box for the PICL to live in

[ortek_service]

Originally Posted by Phil__G

KitbugPlus responds to an input error or invalid command by attempting to put a '?' under the error using linefeed, and just pressing enter is an invalid command - so what you've seen is right Owen

Yes, Kitbug+ did seem quite logical in its response to pressing Enter with no other characters typed - Although, I hadn't appreciated it was a bit more sophisticated than most Command Line Interfaces, in trying to show the error with a '?' under it, so thanks for highlighting that.

What I had actually been trying to show, in summarising it's behaviour alongside that of NIBL, was how NIBL seemed to be different from Kitbug+, with it only sending a LF, and no CR, when you just press 'Enter'
- unless that too was trying to highlight an input error, by putting prompt under it? (However, setting TeraTerm Receive Linefeed to CR or Auto, did give you a more conventional return to the display's first column.). And it only send CR + LF's, when responding to a valid command like 'LIST' etc.


I've never got to use the original NIBL on a real SC/MP yet, so not sure if that was exactly the same. But co-incidentally, I've just come across some old posts on here from Karen Orton, which detailed how difficult it was to run that anymore, as required 110baud (which it seems many modern PC Interfaces no longer support) and said this was one of the motivations in creating PICL NIBL, to allow people run this more-easily.

[Phil__G]

Originally Posted by DavidMS

Anyway as you can see in the attached screen shot I managed to load a relatively long program (first time)

Great stuff David, it has its quirks but works very well once you're accustomed to it

Sorry I didnt explain this earlier, its been a while since I did anything with NIBL, I'd forgotten about the local echo effects
in fact it didnt click until I watched a bit of the video linked above (post #66)

.

[Phil__G]

...and here in the PICLv2 video:
https://youtu.be/d4PSkEpVwAE?t=550
With receive set to 'auto' it functions exactly the same but does look neater

[DavidMS]

Just asking for a 'friend' but is one able to trash Kitbug+ using the hex load function....

At a loose end earlier I thought I would give loading life.hex a go. I had an initial 'hiccup' which was down to me but on the second attempt the load seemed fine with the "done" message. However when I tried to run it @ 1800h it printed a line of 'H' and froze. On rebooting NIBL seems fine but Kitbug is clearly not happy...

I can still get to the load / save option on reset

Anyway I can re-program the PIC if needed so not the end of the world

[DavidMS]

Originally Posted by Michael - K8LH

The 16F18877 code adds to the wonderful features introduced in Phil's PICL Version 2 Update while Karen's SC/MP emulator engine portion of the code remains practically untouched.

While the '877 or '877A uses all 8K (words) of its program memory for the SC/MP engine (4K) and the NIBL BASIC ROM image (4K), the 16F18877 comes with 32K (words) of program memory so we use an additional 8K to store an image of Page 1 and Page 2 RAM memory (see drawing below).

The serial port baud rate is 9600 bps instead of 1200 bps.

The system loads the Page 1 and Page 2 image and the Kitbug+ Monitor into RAM during power-up then presents a [C]old, [W]arm, [K]itbug+ Monitor? prompt.

A program in Page 2 will Auto-Run when you select [W]arm start, assuming you've saved the Page 1 & Page 2 image. NIBL was designed to Auto-Run a program in Page 2 if it detects that Page 2 is ROM. We simply modified a single byte in the NIBL ROM image to bypass the test when selecting a [W]arm start.

The Sense B + Reset sequence Phil introduced in his PICL Version 2 update to provide Hex load capability now presents a [L]oad HEX, [S]ave to Flash? prompt. The [S]ave option copies an image of Page 1 and Page 2 RAM to the image store in PIC Flash memory and this is the image loaded into RAM during power-up or reset.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The 16F18877 can be programmed with the new PICL 16F18877 firmware using an Arduino Nano or Uno. I can post the Arduino sketch if requested.

Cheerful regards, Mike McLaren, K8LH (Michigan, USA)

Mike, could re-post or point me to the latest 16F18877 code and the Nano Sketch as it looks to be easier that having a fight with MPLAB

Thanks

[Phil__G]

Originally Posted by DavidMS

... is one able to trash Kitbug+ using the hex load function....

You can overwrite KitbugPlus in RAM (at 2C00h) for the current session but on the 16F18877 version it will be restored on reset and [K]. Theres no need to reprogram the PIC David.
So 'yes and no'. You can, but its only temporary and fixes itself
On the 877 nvram version if you overwrite KB+ just reinstall it with the hexload function, files are on philg.uk , takes seconds
Cheers
Phil

[DavidMS]

Ok that makes sense it seems to be happier now, I am thinking I probably did not
Leave it unplugged for long enough - to let the elect cap fully discharge - just a reset did not seem to do it - will maybe try moding the reset to a more ‘classic’ version with a capacitor and diode etc

[Phil__G]

Here's a demo of me deliberately corrupting KitbugPlus (actually just the prompt), then being 'saved' and 'restored' on the PIC16F18877 version:
Other than me inserting the red comments its a straight copy & paste from my Teraterm screen:

[ RESET ]
Loading RAM Image: $1100-$2FFF

PICL/NIBL 8K - (C) Karen Orton
[C]old, [W]arm, [K]itbug+ Monitor? K [ SELECT K FOR KB+ ]

[ NOW DELIBERATELY CORRUPT THE KITBUGPLUS PROMPT: ]
Kitbug+ > M2C49

2C49 4B 43
2C4A 69 61
2C4B 74 .
?

Catbug+ > [ NOW KB+ IN RAM HAS A CORRUPTED PROMPT! ]

[ NOW TRY TO SAVE CORRUPTED KB+ TO FLASH WITH SENSE-B & RESET ]
[L]oad HEX, [S]ave to Flash? S
done

[ RESET ]
PICL/NIBL 8K - (C) Karen Orton
[C]old, [W]arm, [K]itbug+ Monitor? C [ COLD START ]

>LINK #2C00 [ RUN KB+ AS IT REMAINS IN RAM ]

Catbug+ > [ AND ITS STILL CORRUPTED, AS EXPECTED ]

[ RESET ]
Loading RAM Image: $1100-$2FFF

PICL/NIBL 8K - (C) Karen Orton
[C]old, [W]arm, [K]itbug+ Monitor? K [ SELECT K FOR KB+ ]

Kitbug+ > [ AND THE CORRECT CODE IS RESTORED ]

[DavidMS]

Phil,

Thanks as I said the difference I found was that I need to cycle power to get ut happy again, although that could have been the serial port - usb adapter playing up. Anyway It's happily running life now

[Phil__G]

Since it was only a demo I just pre-set the starting pattern, before running it you can edit it with the KB+ modify command if you like, just one cell can make quite a difference!
The grid is from 18D6h to 1B15h and contains either 0 (dead) or 1 (alive), not very efficient but hey ho

Pleased to hear yours is sorted
BTW in the session recorded in the previous post there were no power-cycles, just a dab of the reset button... I wonder if maybe it was just crud in the Teraterm rx buffer?
(Edit, Clear buffer. and Control, Reset port) are handy commands, (Setup, terminal) is 80X25, rx=auto & tx=CR, VT100 & local echo on.

Cheers
Phil