Anyone building a PICL? more PCBs available

[DavidMS]

In terms of memory is there somewhere I can ‘put’ code which is not overwritten by a reset ( machine not NIBL) ?

[Phil__G]

With Mikes 18877 code, on reset, page 1 & 2 are always reloaded as they were last saved (plus KB+ from 2C00h), Mikes idea being to avoid the expense of NVRAM.
If say you want to reserve Page 1 for NIBL, 2010h to 2B80h in Page 2 is free, or if you're not using NIBL at all, you can also use 1130h to 1FFFh.
I chose 1800h for Life, 2800h for the lightshow, and 2C00h for KB+, the areas to avoid are 2C00h-2FFFh cos KB+ will re-load there, and the first few bytes of each page (1000h-112Fh and 2000h-200Fh) because NIBL initialises those areas ready for basic programs. Everything inbetween is fair game BUT unless you do a [Save] of your new code, on the next reset it will be overwritten with the last saved Page 1 & 2.
These comments apply only to Mikes PIC16F18877 version, the 877 version doesnt touch anything on reset, instead it relies on NVRAM holding your code, nibl programs, lightshow, KitbugPlus etc.
[actually NIBL clears the first line number on reset, but the rest of the NIBL program and any M/C is left in memory - detailed in the PICLv2 doc]
So in either case, 877 or 18877, you have 3.7k in Page 1 and 3k in Page 2 of free ram to play with
Cheers
Phil

[DavidMS]

Originally Posted by Phil__G

With Mikes 18877 code, on reset, page 1 & 2 are always reloaded as they were last saved (plus KB+ from 2C00h), Mikes idea being to avoid the expense of NVRAM.
If say you want to reserve Page 1 for NIBL, 2010h to 2B80h in Page 2 is free, or if you're not using NIBL at all, you can also use 1130h to 1FFFh.
I chose 1800h for Life, 2800h for the lightshow, and 2C00h for KB+, the areas to avoid are 2C00h-2FFFh cos KB+ will re-load there, and the first few bytes of each page (1000h-112Fh and 2000h-200Fh) because NIBL initialises those areas ready for basic programs. Everything inbetween is fair game BUT unless you do a [Save] of your new code, on the next reset it will be overwritten with the last saved Page 1 & 2.
These comments apply only to Mikes PIC16F18877 version, the 877 version doesnt touch anything on reset, instead it relies on NVRAM holding your code, nibl programs, lightshow, KitbugPlus etc.
[actually NIBL clears the first line number on reset, but the rest of the NIBL program and any M/C is left in memory - detailed in the PICLv2 doc]
So in either case, 877 or 18877, you have 3.7k in Page 1 and 3k in Page 2 of free ram to play with
Cheers
Phil

Thanks Phil this makes it a lot clearer

[DavidMS]

Quick question on the SC/MP emulation, am I correct in thinking the SIO command is not emulated on the NIBL - I'm assuming this as there is nothing labeled SIO...

SIO is included in Karen's original memory map for PIC based MK14 - as RE0 (so only available if you used a 40pin device), but It does not look to have survived to the NIBL ?

[Phil__G]

Karen did several variations of her sc/mp emulation to suit particular projects, the one used in the PICL does rotate the E register on SIO, but doesnt output it to a port pin - neither NIBL or the original Kitbug used SIO for serial comms. The picl does have async serial I/O via Karens three 'new' opcodes $20, $21 & $22 though
The original PICL code didnt have DLY either - that was added with the PICLv2.

[DavidMS]

Originally Posted by Phil__G

Karen did several variations of her sc/mp emulation to suit particular projects, the one used in the PICL does rotate the E register on SIO, but doesnt output it to a port pin - neither NIBL or the original Kitbug used SIO for serial comms. The picl does have async serial I/O via Karens three 'new' opcodes $20, $21 & $22 though
The original PICL code didnt have DLY either - that was added with the PICLv2.

Thanks for confirming - I will just have to use a real 8060

[Phil__G]

Several of Karens sc/mp emulations do have full SIO, she was quite prolific and its nice to occasionally go back over her projects. The stand-alone emulation is probably what you're looking for David
https://www.vintage-radio.net/forum/....php?p=1255238
https://www.vintage-radio.net/forum/...d.php?t=168405 *** (note update in post 15) ***
Cheers
Phil

[DavidMS]

Originally Posted by Phil__G

Several of Karens sc/mp emulations do have full SIO, she was quite prolific and its nice to occasionally go back over her projects. The stand-alone emulation is probably what you're looking for David
https://www.vintage-radio.net/forum/....php?p=1255238
https://www.vintage-radio.net/forum/...d.php?t=168405 *** (note update in post 15) ***
Cheers
Phil

As you say great to look these periodically. That said whenever I look at how neat and well built Karen's projects are I am left with feeling somewhat inadequate - struggling to produce a mechanical build which is as good as I had envisioned.

[Phil__G]

I've been using the 877 version of the PICLv2 with the NVRAM again and found the 1200 baud interface tiresome after Mikes 9600, especially when running Life, so I've patched a 9600bd version of the 877 PICLv2 code and added it to PICLV2FILES.ZIP on the PICL page of http://philg.uk
I much prefer 9600, but the only disadvantage is with the reduced bit timing it takes a few more stabs of ctrl/C to break a running NIBL program
Karen noticed this herself even at 1200bd in her amusing rant: https://www.vintage-radio.net/forum/...d.php?t=168499

Not related, I bought four 877A chips and three run on the PICLv2 just fine, but one programs & verifies ok but wont run. They have no speed markings so they're probably blacktopped 4mhz chips. Still, at the price, 3 out of 4 is ok, its quite likely that the 'bad' one is just slow & will be ok at 4mhz in another project

[DavidMS]

Originally Posted by Phil__G

I've been using the 877 version of the PICLv2 with the NVRAM again and found the 1200 baud interface tiresome after Mikes 9600, especially when running Life, so I've patched a 9600bd version of the 877 PICLv2 code and added it to PICLV2FILES.ZIP on the PICL page of http://philg.uk
I much prefer 9600, but the only disadvantage is with the reduced bit timing it takes a few more stabs of ctrl/C to break a running NIBL program
Karen noticed this herself even at 1200bd in her amusing rant: https://www.vintage-radio.net/forum/...d.php?t=168499

Not related, I bought four 877A chips and three run on the PICLv2 just fine, but one programs & verifies ok but wont run. They have no speed markings so they're probably blacktopped 4mhz chips. Still, at the price, 3 out of 4 is ok, its quite likely that the 'bad' one is just slow & will be ok at 4mhz in another project

Out of interest is the SIO instruction implemented on the 877A version, I am assuming CSA works correctly on this ?

[Phil__G]

Hi David, on the 877 version of the PICLv2, CSA does work correctly in KB+ and NIBL, the 'button test' programs work fine.
SIO is partially implemented, there are no hardware SIN & SOUT pins on the PICL so whilst it does correctly rotate the E register on SIO, it doesnt in or out any bits to port pins. There aren't enough pins - I could maybe pinch the I/O LED pin for SIN or SOUT (but not both), is it input or output you particularly need, whats the plan?
Cheers
Phil

[DavidMS]

Originally Posted by Phil__G

Hi David, on the 877 version of the PICLv2, CSA does work correctly in KB+ and NIBL, the 'button test' programs work fine.
SIO is partially implemented, there are no hardware SIN & SOUT pins on the PICL so whilst it does correctly rotate the E register on SIO, it doesnt in or out any bits to port pins. There aren't enough pins - I could maybe pinch the I/O LED pin for SIN or SOUT (but not both), is it input or output you particularly need, whats the plan?
Cheers
Phil

Phil, it's output - I quite like to use 595's as simple parallel output devices. Clearly I could engineer the serial out on F0-2 but it seems a waist when there is already an instruction to output serial data

[Phil__G]

The code would be pretty much the same though, remember SIO only outputs one bit, unlike a uart all the timing and shifting/clocking of 8 bits would need to be software driven...
I'll have a look tonight
Cheers
Phil

[DavidMS]

Originally Posted by Phil__G

The code would be pretty much the same though, remember SIO only outputs one bit, unlike a uart all the timing and shifting/clocking of 8 bits would need to be software driven...
I'll have a look tonight
Cheers
Phil

It's quite a standard way to add IO lower IO count Arduinos, as I said it seems a pity not to use if SIO is there.

I guess my goal in the background is looking towards some business travel coming up in June I would like to have a small self-contained development 'system' I can keep myself amused with in evenings (helps keep me out of the bar). ideally I would take a replica MK14 but it is too large, your PICL board is ideal being compact and easy to connect to using a terminal program (accepting that my employers IT department bans any terminal apps from work PCs). I just want to add some extra flashing lights !

[Phil__G]

Sorry if I've misunderstood you David but behind the Arduino's 'shiftOut()' is a cpp function and ultimately many object code instructions to make it shift a byte out in one call. In combination with a 595 shift register shiftOut() needs two pins, for data and clock.
The SC/MP instruction SIO is quite different, its a single opcode that literally shifts out just one bit, onto one pin (whilst shifting in one bit from another pin). If you wanted to clock a byte into a 595 you would need software to do SIO 8 times whilst outputting a clock pulse per bit on another pin (which we dont have). It would be just as easy to put a 595 on two flag lines, the routine to shift a byte out of the flags would be almost identical to using SIO. You could even write it in NIBL basic
Sorry if I'm teaching granny to suck eggs, I'm not sure if the SIO vs shiftOut() disparity is appreciated
Cheers
Phil

[DavidMS]

Originally Posted by Phil__G

Sorry if I've misunderstood you David but behind the Arduino's 'shiftOut()' is a cpp function and ultimately many object code instructions to make it shift a byte out in one call. In combination with a 595 shift register shiftOut() needs two pins, for data and clock.
The SC/MP instruction SIO is quite different, its a single opcode that literally shifts out just one bit, onto one pin (whilst shifting in one bit from another pin). If you wanted to clock a byte into a 595 you would need software to do SIO 8 times whilst outputting a clock pulse per bit on another pin (which we dont have). It would be just as easy to put a 595 on two flag lines, the routine to shift a byte out of the flags would be almost identical to using SIO. You could even write it in NIBL basic
Sorry if I'm teaching granny to suck eggs, I'm not sure if the SIO vs shiftOut() disparity is appreciated
Cheers
Phil

No you are correct, not forgetting a 3rd line is needed to transfer to the output register but given the SIO is there it's marginally easier to use than using all three flags

[Phil__G]

Hi David, here is an 877 version which runs 9600 baud and has the console activity LED repurposed as the SC/MP SOUT pin. If you use SIO the LED will indicate SOUT status, and the SOUT signal will be on the IO pin of the 10-way header:

PICLV2_9600sio.HEX (right click, save link as)

There is no SIN, not enough pins on the 877, so SIN is always read as a zero level, so after 8 SIO instructions EX will contain eight zeros, each having been shifted in from bit 7 down (SIO is a right-shift)
Let me know how you get on with it please, its only had a quick test...
Cheers
Phil

PS I found an answer to the NIBL break-in problem at faster baud rates, as noted by Karen...
Its so simple - ALT/B to send a hardware 'break' signal! Works a treat, every time!!!

[Phil__G]

I've updated the link above, I realised I was setting SOUT to bit 0 after the EX shift, of course it should be before. In effect its a 9 bit right-shift.
Its a bit like RRL 'rotate-right-with-link' into carry, but instead of carry its a physical pin.
Also, I changed the fixed level of SIN to 1 rather than 0, this means 7 bit serial ascii can be easily output using bit0 low for start, b7-b1 as the 7-bit ascii (will need a left shift first) and the incoming ones from SIN will act as stop bits. I cant think of a disadvantage of defaulting SIN to 1 rather than 0 as before so try it & let me know what you think.

So the statement above
"so SIN is always read as a zero level, so after 8 SIO instructions EX will contain eight zeros, each having been shifted in from bit 7 down (SIO is a right-shift)"
now reads
"so SIN is always read as a high level, so after 8 SIO instructions EX will contain eight ones, each having been shifted in from bit 7 down (SIO is a right-shift)"
Cheers
Phil

[DavidMS]

Slight dyslexia issue after struggling to program PIC discovered it was a 16F887 not a 16F877.... off to search my component stocks with magnifying glass

[Phil__G]

Ok that works nicely:

https://youtu.be/5NFXpMBwC0U

Theres a .zip on the PICL page of http://philg.uk under 'useful files'