SC/MP programming chat.

[Phil__G]

Split from this thread:-

https://www.vintage-radio.net/forum/...d.php?t=186247

Thanks Ian - I set my delays 'generously' and never did get around to trimming them. I'll update the file, I hope you dont mind me posting it, its your baby after all

Originally Posted by SiriusHardware

...if the webserver or other utility reading the Intel file finds no execution address in the file then it should send the last three bytes as 00h 00h 01h, (End of file, execute from 0001h) which will tell the fast loader to execute the monitor.

Hmm... I dont think that idea will work unfortunately
The monitor relies on a hard reset having reset the pointer registers to zero on startup rather than whatever they contain before the jump - eg:
A CS2 sequence of:
0x00 no more data, exec address follows)
0x00 exec address hi
0x01 exec address low
...will result in a display of "0022 3F" (debug entry point) rather than a clean monitor restart
Or, if you enter 0000h or 0001h and "Go", the same thing happens
Harmless, but untidy

I've found that the Intel Hexfile ideally needs to end with one of three things -
1) no Intel EOF record (':00000001FF' would be wrongly read as exec at 0000 and consequent "0022 3F") - so omit it, & reset & go manually
2) a valid CS2 autorun record such as ':000F20'
3) a valid Sirius autorun record such as ':02FFFE000F20cc'

method 1 means manually deleting a line from the Intel Hex file
method 2 is neat but I havent found a way to make sbasm create it, so its a manual edit of the hexfile again
method 3 is easy for SBASM to create with no manual editing.

These are just my ruminations after playing with SCIOSv3 and my Intel converter/loader for a few days so not by any means the voice of experience here
Although (and I'm quite proud of this...) I did land on the moon once...

[SiriusHardware]

Hmm... I dont think that idea will work unfortunately

That's weird, as it already seems to have been tested a number of times over.

Have you actually tried starting the loader code on the MK14 and sending 00 00 01 to it to see what it actually does? CS2 may have implemented whatever needs to happen within the loader to make it work.

[SiriusHardware]

1) no Intel EOF record (':00000001FF' would be wrongly read as exec at 0000 and consequent "0022 3F") - so omit it, & reset & go manually

No, deleting the Intel EOF line would create the need for non-standard Intel Hex files. Instead of removing the Intel EOF line, simply have the loader discard Intel Hex lines which have record type '01'. That's what my Pi-uploader and various spins of it do.

[Phil__G]

`Sorry G "edit window of doom" again, I meant to say
"I dont think that will work as expected" but was too late.
I just tried my first Slothie and I get the same, either "0000", "Go", "0001", "Go" or sending either 0x00,0x00,0x00 or 0x00,0x00,0x01 via the fast-loader doesnt re-enter the monitor cleanly with a "0000 00" display for me, but shows the debug entry point of "0022 3F". If everyone elses is re-entering cleanly with "0000 00" I must have a problem common to both slothies, I'll investigate
Sorry to cast nasturtiums
Phil

[SiriusHardware]

See posts approx. 152 to 158 of this thread which appear to suggest that the jump to 0001 is handled by Coolsnaz2's code in such a way that it does seem to work:-

https://www.vintage-radio.net/forum/...=186247&page=8

If everyone elses is re-entering cleanly with "0000 00" I must have a problem common to both slothies, I'll investigate

Not with 00 00 00, but 00 00 01. Coolsnaz's code adjusts the value passed to it by -1 in anticipation of the fact that the processor will then pre-increment the PC before fetching the next instruction.

I'm going to have to try this out myself now. Not saying you are wrong Phil, but it is hard to believe this is only being picked up now.

[Phil__G]

Originally Posted by SiriusHardware

Instead of removing the Intel EOF line, simply have the loader discard Intel Hex lines which have record type '01'. .

until I tried it with the results above, I assumed that when a standard EOF ':00000001FF' is interpreted as zero bytecount, exec address 0000, and therefore jump to 0000, would be a good monitor re-entry, which it is for everyone else - but not on mine, which I need to sort out

[Phil__G]

Originally Posted by SiriusHardware

Not with 00 00 00, but 00 00 01. Coolsnaz's code adjusts the value passed to it by -1 in anticipation of the fact that the processor will then pre-increment the PC before fetching the next instruction.

Sorry yes I understand that G but sorry I wasnt clear, I'm talking about the display which on re-entry at address 0x0000 OR 0x0001 does not show "0000 00" on the MK14 display as it would after a hard reset.
Instead on re-entry at either hex address 0000 or 0001, mine shows "0022 3F" on the display.
Sounds like yours is ok - try a hard reset, then press Go.
I expect your display shows "0000 00" whereas I get "0022 3F"

This doesnt re-boot the monitor for me...

LDI 0
XPAH P3 ; zero P3
LDI 0
XPAL P3
XPPC P3 ; Restart SCIOS at 0x0001

[SiriusHardware]

Bit late for me to try this (I don't have your evidently nocturnal way of life) but I will try to give this a shot tomorrow.

[Mark1960]

If you hit go after a hard reset then the MK14 will start executing from 0000, until it hits the first XPPC P3. This is the one that normally starts the user program when you hit go. This is where you get 0022 3F, and is expected.

[Phil__G]

Thanks for doing the split Graham, much appreciated - much better that we dont divert Coolsnaz2's thread with off-topic stuff. Cheers!
We can use this for programming Q & A, ideas, problems, puzzles...

So on topic, we were discussing whether clearing P3 and XPPC P3 giving a jump to zero (+1) has the same effect as a hard reset...

[SiriusHardware]

Phil, I've 'adapted' your loader .ino sketch to do nothing more than send three CS2 protocol bytes in a row - unfortunately I have been commandeered for most of the rest of the evening so I won't be able to get it all wired up until later, if at all, today. The SCIOS 3 code in your PROMs was programmed from two files read out from the ones in mine which are themselves copies of the very first ones I made and sent to Coolsnaz2, so we should all be running the same version of the MK14 side loader code.

The other thing I can do is to try the M5 Atom which CS2 kindly provided me with and see how it handles (a) an Intel Hex file with an Autorun address and (b) the same Intel Hex file without one. For the second case I'm sure he provided a specific handler in his M5 side loader code for what to do if the Intel hex file wasn't found to contain an execution address.

As far as I know you have to tell the MK14 side loader where to go after loading is complete by providing a goto address in the CS2 'end' line because there wasn't enough memory available for it to have a 'if no execution address provided' branch and handling code.

I suppose if you didn't provide it with an 'end' line then it would just wait indefinitely for the next valid data line to come along, which it won't, so then you could just manually reset the MK14 when the 'send' LED on the host stops flashing.

[Phil__G]

Initially I'd provided for a manual edit of a hex file to make it easy to add autorun,
You'd just replace the EOF with :00xxxx (xxxx=exec addr)
Since then I added the Sirius autostart so I dont think the first idea is necessary, and it did mean the file was no longer strictly Intel format - so I think I'll remove that leaving only the Sirius autorun.
Still unsure of the question of what to do is no Sirius autorun line is found - defaulting to address 0000 (+1) seems an untidy way to end with the display showing "0022 3F".
Although the monitor does seem stable at that point & accepts further commands ok, the likely user response to that in any case would be to press reset, enter the exec address manually & Go
I keep tweaking the Intel to CS2 sketch so your download is probs out of date

Edit: I just removed the first idea leaving the Sirius autorun prominent. Actually its still there but in stealth mode
Uploaded a few mins ago

[SiriusHardware]

Well, the one I have at the moment I just grabbed from your site a couple of hours ago but I have no idea how often you update that one on your website. I did notice it has the facility to handle 'my' autorun address format.

It could be that I have the way Coolsnaz2's M5 host-side loader handles the no-address-found case completely wrong, it may do something else entirely. As I mentioned above one work around is just not to send an 'end' sequence at all if you don't find an autoexec address in the Intel file. Once the 'sending' LED on the host has stopped flashing, just reset the MK14 manually to break out of the MK14-side loader and return to the standard monitor prompt.

[Phil__G]

Updated a few minutes ago G, you should see a zip now.
I usually add a variable like ?k=7 or similar to the end of the URL to force a refresh.

[SiriusHardware]

I still haven't been able to investigate what Coolsnaz2's loaders do in the 'no execution address found' situation but it occurs to me that there is another way to handle this although it involves the use of one more logic output (a reset signal) from the host / sender.

If the sender finds that the source Intel Hex file contains a valid Autorun address, then after sending the file to the MK14 in CS2 protocol format it should send the 'end' line 00 AH AL to inform the loader that it should jump to the execution address. This already happens.

If the sender finds that the source Intel Hex file contains no valid autorun address, it should NOT send an 'end' line, but instead should momentarily toggle a third logic-level output on the sender. This output could be used with a simple output level converter (a transistor or optocoupler) to initiate a hardware reset of the MK14, which will force a clean restart of the monitor.

The main thing to watch out for is that on original issue V boards and clones of the same, the reset switch pulls the reset input (which is inverted on those boards by a single inverter before it goes to the SC/MP) to +5V, not 0V - therefore the safest reset-output circuit to use, one which will work with all MK14 board revisions, is an optocoupler with its output emitter connected to the reset capacitor -ve and its output collector connected to reset capacitor +ve. There should also be a lowish value (~100R) resistor in series with the opto output transistor collector otherwise the transistor, when activated, will instantly discharge the fully charged reset capacitor through itself, which may not do it much good in the long run.

[Phil__G]

Sense B is initialised low by the external loader until it starts the transfer, then it pulses before returning low after the last byte transferred. A retriggerable monostable could spot if Sense B is held high, that would save a wire but would need another chip...

But now I know its normal and theres nothing wrong with my MK14s I dont mind the "0022 3F" caused by a 'jump-to-location-zero' any more - and it only happens with non-autostart hex files - at that point (0022 3F) you can use any command keys or habitually I just press reset
After all Nick Toops standard tape reader needed a reset
My converter has an accidental catch-all in that a standard Intel EOF :00000001FF is read as a 'no bytes, exec from location 0000'

[SiriusHardware]

A retriggerable monostable could spot if Sense B is held high, that would save a wire but would need another chip...

I think it would be a little bit mad to have to add an actual chip circuit when the loader can already generate a context-sensitive reset signal with just one more output.

For those with MK14 replicas which already have a 'pull low to reset' input available on one of the edge connectors, and assuming the use of a 5V-logic device like the majority of Arduinos, you could use one of the I/O ports of the Arduino in psuedo-open-collector mode by:

Initialising it in input mode
Setting its output latch to logic 0

Then, to reset the MK14, you just momentarily swap the port pin from input mode to output mode and back to input mode. The port pin will drive the MK14 reset input low, then release it high. No extra hardware involved, just one more wire.

As stated above though this approach would not necessarily work with the specific MK14 versions which need their reset-input line pulled high - but you could provide a second 'reset output' pin on the sender which toggles between input mode and driven high, specifically for those MK14 variants.

[SiriusHardware]

Update: finally had a moment to get my M5 ATOM webserver uploader running with the issue VI. It's impressively fast.

-Used it to upload MESSAGE.HEX with integral 'Sirius Autorun' address embedded - program uploaded and auto-ran as expected.

-Removed the 'Sirius Autorun' line from the MESSAGE.HEX file and saved as MESSAGE_NAR.HEX (NAR =No Auto Run) - program uploaded and loader exited to '0022 3F' prompt exactly as per your findings, so we can assume that in the absence of an autorun address in the file Coolsnaz's own loaders do the jump to 0001, with the same result.

Although untidy, it seems harmless and does not seem to affect the loaded code in any way.

One other thing to watch out for is that the CS2 loader uses 3 addresses (0FF8, 0FF9, 0FFA) high up in the 'standard' RAM for its variables, this means that if you try to load code which is intended to reside at those addresses the loader will break its own operation when those bytes are overwritten.

[Phil__G]

Thanks G, confirms what we expected, its all good

[Phil__G]

Pending a proper Intel Hex feature for KitbugPlus (its a wip!), this crappy basic program will strip the data bytes out of an Intel Hex file into a format that can be spooled from Teraterm into the Kitbug 'modify' command:

10 INPUT "Input hexfile";H$
15 PRINT "SET CHARACTER DELAY TO 50MS, LINE TO 200MS"
20 PRINT "TYPE M COMMAND IN KITBUG, THEN SEND FILE OUT.DAT"
50 OPEN H$ FOR INPUT AS 1
60 OPEN "OUT.DAT" FOR OUTPUT AS 2
70 WHILE NOT EOF(1)
100 LINE INPUT #1,L$:L=L+1
105 N=VAL("&H"+MID$(L$,2,2))
130 FOR B=10 TO (2*N+8) STEP 2
140 D$=MID$(L$,B,2):PRINT #2,D$
160 NEXT:WEND
190 PRINT #2,"."
200 CLOSE #1:CLOSE #2

Type Mxxx (return) (where x is the address)
then send the OUT.DAT file from Teraterm. Its really naff but works, for now its better than manually keying endless code!