Anyone building a PICL? more PCBs available

[Phil__G]

Cool, where did you find the Ramtron fram Chris?

[ChrisOddy]

Funny you should ask that, try here: https://theoddys.com/acorn/shop/comp...ents_shop.html !!

[Phil__G]

Only £3 ? absolute bargain!

[DavidMS]

Another PICL up and running, with a bit of ‘help’

[Phil__G]

I love to see these projects completed
I still have a few boards if anyone fancies a go
https://www.vintage-radio.net/forum/...d.php?t=185066

[DavidMS]

So slightly odd discovery for the morning, my current preferred terminal program is Coolterm, but even with a good bit of fiddling I am struggling to get it to work properly with NIBL - kitbug seems ok. So after a fruitless half an hour I tried it with TeraTerm and other than setting local echo to 'on' it worked straight out of the box. My thinking is that it is something to with CR / LF handling - on screen it looks like Coolterm is 'seeing' random linefeeds. the PICL is getting the commands correctly as far as I can tell. Anyway I am not that wed to Coolterm so happy to use TeraTerm, it's just a bit mystifying

[Phil__G]

Hi David, I have Teraterm set to CR on transmit and 'auto' on receive which I think is the default. Both NIBL & KitbugPlus both send strings terminated with CR and LF (0Dh,0Ah) as you'd expect but there shouldnt be (can't be?) random LF's coming from the PICL, only the expected ones in a CRLF sequence.
Far more likely Coolterm is sending an LF after CR, NIBL & Kitbug kick into action on the CR leaving the LF in the buffer so it appears to 'preceed' the next command from Coolterm. Check you dont have 'LF' set 'on' on transmit, or autoLF?
Cheers
Phil

[ortek_service]

Originally Posted by ChrisOddy

and another PICL arrives, thanks Phil !

I presume you programmed your PIC16F877A, and did have this running, after assembling it?

I see you also used one of those FTDI TTL-232R-5V USB-Serial-UART leads, as we found its standard connector pinout matches that used on those 'CH340G for WEMOS.CC Mini' modules (That we hadn't got any around yet, and seem less-common than ones built onto a USB type A plug-PCB with a different pinout 5-pin header, instead of 6way socket, although are on eBay / Amazon)
- for the pins that are actually required at least, as pin6 (DTR on CH340G-module, but RTS on FTDI TTL-232R), and pin2 (RTS/CTS link-selectable on CH340G module, as they've re-used the FTDI 'standard' RTS pin for DTR, but always CTS on the TTL-232R connector) are not connected on Phil__G's PCB.

Luckily, I've also got one of those FTDI TTL-232R leads in the original 5V-version (I've many more of the 3.3V-levels version, but I'm not sure they will quite work with this PIC16F877 etc. if the Port-E input is configured as a schmitt-input with > 0.8 * 5Vdd as standard - so even-higher than 2/3 * 5Vdd for CMOS - rather than >2V for inputs using TTL-mode).


I found it surprising that the serial seems to be using bit-banging on this PIC16F877 - Presumably. as its dedicated USART Rx/Txpins on PortD are already being used for lower address bus to RAM (Although not in order, so may not have been much different for the firmware to swap A6/A7 on Port D serial pins with port E ones).
I also discovered that the PIC supports a 'Parallel Slave Port' for use in interfacing to a microprocessor bus, but only on Port D, whereas Port B has been used for Data-bus to RAM. So had wondered if this PSP mode might hae been useful (Not sure if needing 2 other ports for address lines meant standard PSP mode wasn't any benefit).
I presume the original pin-allocations were based on simplifying a verobaord layout, even if it meant making the firmware rather more complicated to sort-out non-sequential ordering of address & data buses.

[ortek_service]

Originally Posted by Phil__G

A few have asked about using an 877A
Tony used one in his:
https://www.vintage-radio.net/forum/...30#post1439530
But I'd suggest Mikes 18877 version if you can program them, if not I can supply preprogrammed at cost, currently £2.50+vat from RS
Its pin-for-pin so a straight swap.

Chris & I would like to try Mike's 18877 version, so thanks for offering to supply these, and I've sent a PM about buying some from you.

[ChrisOddy]

Originally Posted by ortek_service

I presume you programmed your PIC16F877A, and did have this running, after assembling it?

I see you also used one of those FTDI TTL-232R-5V USB-Serial-UART leads, as we found its standard connector pinout matches that used on those 'CH340G for WEMOS.CC Mini' modules (That we hadn't got any around yet, and seem less-common than ones built onto a USB type A plug-PCB with a different pinout 5-pin header, instead of 6way socket, although are on eBay / Amazon)
- for the pins that are actually required at least, as pin6 (DTR on CH340G-module, but RTS on FTDI TTL-232R), and pin2 (RTS/CTS link-selectable on CH340G module, as they've re-used the FTDI 'standard' RTS pin for DTR, but always CTS on the TTL-232R connector) are not connected on Phil__G's PCB.

Luckily, I've also got one of those FTDI TTL-232R leads in the original 5V-version (I've many more of the 3.3V-levels version, but I'm not sure they will quite work with this PIC16F877 etc. if the Port-E input is configured as a schmitt-input with > 0.8 * 5Vdd as standard - so even-higher than 2/3 * 5Vdd for CMOS - rather than >2V for inputs using TTL-mode).

Programmed the 877A on my TL866CS and yes I've used a 5V FTDI serial to USB and used Putty for a serial client.

[DavidMS]

Originally Posted by Phil__G

Hi David, I have Teraterm set to CR on transmit and 'auto' on receive which I think is the default. Both NIBL & KitbugPlus both send strings terminated with CR and LF (0Dh,0Ah) as you'd expect but there shouldnt be (can't be?) random LF's coming from the PICL, only the expected ones in a CRLF sequence.
Far more likely Coolterm is sending an LF after CR, NIBL & Kitbug kick into action on the CR leaving the LF in the buffer so it appears to 'preceed' the next command from Coolterm. Check you dont have 'LF' set 'on' on transmit, or autoLF?
Cheers
Phil

Thanks, I had tried these it is something to with Cool term not the PICL, I switched back to my Elektor Z80 and I seem to be able to hit that with text to load basic programs a lot faster with Teraterm - so I guess TeraTerm will be my new go to terminal emulator

[ortek_service]

Yes, have often used TeraTerm as a better replacement for Hyperterminal, when MS stopped including that in Windows / made it a pain to find where to get it from to install.

RealTerm is also very handy, with useful lower-level debugging options like displaying in hex, that used to be mainly only in old DOS programs like Mirror-III, and more control over handshaking.

I've not tried Putty yet, but Chris uses it and seems to have it working with NIBL.


I'd never heard of CoolTerm until now, so not sure how good that is.

[ortek_service]

Originally Posted by ortek_service

Chris & I would like to try Mike's 18877 version, so thanks for offering to supply these, and I've sent a PM about buying some from you.

Thanks Phil for sending me some Programmed PIC16F18877's, I received earlier - Please let me know how to make payment to you (PM also sent).

Another PICL NIBL now completed (Plus I've passed a PIC16F188877 to Chris, who's tried it in his board, as well). And also using the Ramtron FM1608-120-PG DIL28 FRAM, I'd found were available for less than the SM-adaptor board ones / many NVRAM's on the 'Bay (at 10off, at least), and mentioned in a previous post / to Chris, who then ordered some.

I actually first had it running with a FTDI TTL-232R-3V3 cable, as I hadn't got a TTL-232R-5V cable with the original-connector (that directly plugs into this PCB's header) still on at the time. Although the PIC's RE0/1 pins (that normally have a weak internal pull-up to 5V as measure that), were getting loaded down to 4.2V / 3.3V by the FTDI cable - So probably best not to use a 3.3V levels one long-term. And I'm now using a 5V-levels one, with >4V on both TxD & RxD.

I ran a FOR-Loop to count 0-15 as binary pattern to LED's. But it was a bit too-fast for photo (always showing all-on)
So I also did a short video on camera - See attached photo & video-clip (Zipped-up, to allow file type)

But I've not worked-out yet how to save programs on this version / why both Cold & Warm start after reset, seems to clear the program from memory (with Warm start inserting a 100 PR PAGE line and running it) - Chris had also found first 2 bytes (line no) of programs were over-written, on the 16F877 version.

And Reading STAT, always gives 191 (10111111 binary pattern), with Sense A & B switches not altering this - Have checked voltage to pins is changing OK.

[ortek_service]

Originally Posted by ortek_service

Yes, have often used TeraTerm as a better replacement for Hyperterminal, when MS stopped including that in Windows / made it a pain to find where to get it from to install.

RealTerm is also very handy, with useful lower-level debugging options like displaying in hex, that used to be mainly only in old DOS programs like Mirror-III, and more control over handshaking.

I've not tried Putty yet, but Chris uses it and seems to have it working with NIBL.


I'd never heard of CoolTerm until now, so not sure how good that is.

I've now tried PICL NIBL with a few Terminal Emulator programs, and had it working OK, with:

TeraTerm (Has versatile choices of CR / LF combination to send and receive new-lines as - I found PICL NIBL only sent LF to PC, with no CR).
Plus TeraTerm also does telnet & SSH.

PuTTY (Latest 0.78 Oct'22 version, but found it doesn't auto-find USB Serial COM Ports in a list and you have to enter COM-Port no. each time)

RealTerm (both a >10yr old v2.0.0.70 version, and the latest I could find 3.0.1.45_Beta2 from 2018 (seems Delph it used, isn't supported much any more, but it looks like source code is also available) at: https://www.i2cchip.com/realterm/ - as Sourceforge seem to still have older 2.0.0...).
With RealTerm, to get Local-Echo you have to go to 'Display' settings, and tick 'Half-Duplex'!
- But it does put these in a different colour, to actually received data.
RealTerm also has quite a few I2C debugging stuff in it, inc. reading of DS1820 sensors / writing to various displays (in 2.0.0.70 at least). And latest 3.0.1.45_Beta version I'd also tried, has an I2C-Mem tab, with commands to read etc. Serial-EEPROMs.

This webpage had a summary of Realterm (as well as mentions some others):
https://openlabpro.com/guide/realterm-guide/


I did have a go with CoolTerm (which is also meant to display Hex etc, like RealTerm) , downloading last version for WinXP 32bit. But I couldn't get it to even open the connection for the USB-Serial COM Port it found OK in settings - It just gave a cryptic Setting error message! (I even tried renumbering COM Port from 17 to 4, as some older Terminal programs, didn't like COM Port numbers too-high)

[Phil__G]

Inside the box there should have been a small instruction sheet Owen, maybe it fell out:

PICL using the PIC16F18877

Normal power on asks [W]arm [C]old or [K]itbug?

Power on with Sense-A auto-runs the machine-code
program whose address is at 2FFE/2FFF (lightshow, as supplied)

Power on with Sense-B asks [L]oad Intel hex or
[S]ave current program to flash?

After entering a new NIBL program, to save it hold
Sense-B whilst dabbing Reset, then type 'S'
To load this program, on power up, choose 'W'

NIBL is uppercase only. Set 9600, local echo = on,
line delay 200ms, character delay 2ms
Note different PIC build to suit clock speed:
20mhz xtal for 20mhz, SC/MP 4mhz equivalent

As you see, "W" for warm start loads the last saved program. If you didnt save it, the last saved program is empty. Hope this makes sense!

Re the sense buttons, I just tried the NIBL test program from the PICLV2 document, and you're right!
They work fine with the 877 firmware but apparently not with Mikes 18877 version, I hadnt noticed until now!

10 P=STAT
20 IF P AND 32 < 32 PRINT”YOU ARE PRESSING SENSE-B”
30 IF P AND 16 < 16 PRINT”YOU ARE PRESSING SENSE-A”
40 GOTO 10

Cheers
Phil

[Michael - K8LH]

Hi Phil & gang:

I never built a copy of your board (Karen's design) so I'm at a slight disadvantage. I used slightly different port assignments on my 8K board and newer 32K board designs and then I modified my 8K code for your 8K board with its 'standard' port assignments in the hope that the '18877 swap might be useful.

Anyway, I modified a single instruction in the PIC16F18877 code which may eliminate a potential read-modify-write problem for PORTA. The only other thing I can think of is that the 16F18877 doesn't require external pull-up resistors (internal weak pull-ups are used instead) and I seem to recall the switch test program worked fine on my PICL boards without external pull-ups. I will try to test my boards ASAP.

I've attached updated source, hex, and Arduino files which include the one byte change.

Cheerful regards, Mike

[Phil__G]

Hi Mike, thanks for doing that, unforch it hasnt made any difference - it seems NIBL still cant read the sense buttons on the 18877 version
I'm pretty sure its not the pull-ups, I'm getting a good solid ground on the PIC pin when either button is pressed. The Kitbug+ 'T' command 'stop with Sense B also doesnt work, so it looks like its in the scamp emulation code or a hardware difference in the way the 18877 handles PORTA?
I've never used LATx directly before but reading the datasheet I cant see anything obvious...
Cheers
Phil

[SiriusHardware]

Long shot, but on some of the later PICs the pins which have analogue input as one of their optional modes actually default to analogue input mode and you have to specifically disable the analogue input mode by writing to the ANSEL and ANSELH registers during setup if you want to use the pins as digital I/O.

I think it's usually the PORTA pins which have the ADC input capability, might this be the problem?

[Phil__G]

Its not that G, Mike deselects all the analogues right at the very start:

        org     0x0000
v_reset
        clrf    INTCON          ; global & peripheral IRQs off
        banksel ANSELA       ; bank
        clrf    ANSELA          ; PORTA analog functions off
        clrf    ANSELB          ; PORTB analog off
        clrf    ANSELC          ; PORTC analog off
        clrf    ANSELD          ; PORTD analog off
        clrf    ANSELE          ; PORTE analog off

[SiriusHardware]

No problem, I haven't had reason to look through the source myself but I have certainly been caught out by the analogue-by-default situation at some point in the past which is why it came to mind.