|
Vintage Computers Any vintage computer systems, calculators, video games etc., but with an emphasis on 1980s and earlier equipment. |
|
Thread Tools |
10th Mar 2023, 7:29 pm | #41 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: SoC Mk14 Pico Uploader
Not there yet but I am having one small problem, I can't get it to accept my menutx.txt file, it declares 'Bad menutx.txt file, loading defaults'.
There is some ambiguity over what this file should be called. The uploader itself calls it 'menutx.txt' (which is what I have called it so far, with the lower case 'm') In section 6. iii of the manual the name of this file is given as 'menust.txt' and in the header of the chapter about the config file it is 'Menustx.txt', but the capitalisation is understandable given that it is a heading. I think I probably have the right file name because the uploader is actually finding it but declaring it invalid, so what can I be doing wrong? I'm using a 'simple' text editor (Notepad) to create the menutx.txt file, which is a single line with the numeric characters '101' on it, like that, together, with no gaps. Is that correct? Edit: OK, I had a look through code.py and I realised that the code is expecting the config file to be called menust.txt, so any references to menutx.txt in the manual need to be changed to menust.txt. Next up, with the speed value set to zero the uploader only takes a relatively short while, a few seconds, to send moonlander before returning to the normal menu prompt. With the speed value set to '1' it goes away for a very long time like it's running in slow motion so I thnk it must be picking the same 'slow' speed option when the speed value is '1' or '2'. Last edited by SiriusHardware; 10th Mar 2023 at 7:44 pm. |
10th Mar 2023, 8:20 pm | #42 | |
Pentode
Join Date: Nov 2022
Location: Chesham, Buckinghamshire, UK.
Posts: 135
|
Re: SoC Mk14 Pico Uploader
Quote:
|
|
10th Mar 2023, 8:51 pm | #43 | ||
Pentode
Join Date: Nov 2022
Location: Chesham, Buckinghamshire, UK.
Posts: 135
|
Re: SoC Mk14 Pico Uploader
Quote:
The slow is really slow - essentially for debug. Would be interested in your views if I should add a 'not quite so slow' as a 4th option ? |
||
10th Mar 2023, 9:04 pm | #44 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: SoC Mk14 Pico Uploader
Thanks for the amended code, I will try it as soon as I can.
I haven't actually tried it connected to an MK14 yet, I was only judging the speed by how long it 'went away' for for each selected speed so I'll get back to you on that. One 'cosmetic' option I considered for the Pi version was to have the uploader start off at almost human entry speed so an observer could see exactly what it was doing for the first few entries, then over the course of 3/4 second or so, have it ramp up to the maximum speed. I decided against it because for someone using it for actual development that would get old quite quickly and would just add to the upload time, but it might be fun to have at an exhibition. "What's that thing hanging off the side?" "Oh, that loads code in. It types it in, just like a human operator, so you don't have to" You then run it, and it starts typing the code in at about 1-2 bytes a second just like a human would, and then suddenly accelerates to maximum speed... At the end of the day though, just a gimmick. |
10th Mar 2023, 9:27 pm | #45 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: SoC Mk14 Pico Uploader
One other parameter to include in the menust.txt file might be a '0' or '1' to select the 'OS entry mode'. When I originally made the pi-uploader I only originally supported the entry keystroke sequences required by the 'new' OS because that's what mine had.
Only at the last minute did I relent and include support for the 'old' OS entry mode as well - just as well I did, because someone popped up with an 'old OS' machine very shortly afterwards. |
10th Mar 2023, 10:00 pm | #46 | |
Pentode
Join Date: Nov 2022
Location: Chesham, Buckinghamshire, UK.
Posts: 135
|
Re: SoC Mk14 Pico Uploader
Quote:
|
|
11th Mar 2023, 1:10 am | #47 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: SoC Mk14 Pico Uploader
I still have my original old-PROM set somewhere but I have not seen them for decades. When testing the Pi-Uploader I had to use an EPROM wired to 'look' like a pair of PROMs in order to test that input mode.
At the time there wasn't the availability of Replica PCBs that has come about since, so I was mainly aiming at people who, like myself, still had original machines, some of whom might never have upgraded to the 'new' OS. Apart from not having the cassette tape routines built in, the original OS is truly awful anyway - when I had it 'installed' for the purposes of testing I could not believe I had ever been able to get on with it while at the same time battling with a keypad which only responded to every other key press. For people who have an original machine which has been preserved in working order for all of this time and happens to have 'old' OS PROMs, I can understand why they would want to preserve it as it is now and would not want to remove any original components from it. |
15th Mar 2023, 1:10 am | #48 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: SoC Mk14 Pico Uploader
Another update - got the Pico uploader connected to my issue VI and found to my surprise that it was failing to upload moon landing - I modified code.py a bit so that I could force one particular key to be pressed every time so that it would just flood the address field with that character, and that way I could tell if the interface was activating the right optocouplers to press whichever key was being forced.
I tried this with characters 0-9 and A-F and MEM and all were correct. I was about to go in really deep when it suddenly occurred to me to wonder if the sole hex file I was using was OK - I retrieved a known working moonland.hex file from the computer I normally upload from and Bing! ...working. Absolutely nothing wrong with the interface or its code, just a bad hex file. I suppose this illustrates the danger that we were talking of a little while ago, of leaving known dud code hanging around in attachments to threads. My thanks to DavidMS for working on this and for kindly sending up one of his protoype Pico-uploader PCBs. I'll be happy to assist with any further beta testing required if the code or UI is refined further. This is a particularly good option for anyone with an original machine due to the safety isolation afforded by the optocoupler interface, and it uses no software or hardware resources not already used by the MK14 monitor - it doesn't tie up any of the SC/MP's I/O pins so they all remain available for user use. The original Pi / optocoupler interface loader also had these advantages but carried with it the necessity of having to set up a whole Raspberry Pi and its life support system to load code into the MK14 whereas the Pi Pico based version presented here by DavidMS, with its built in display and UI, is much more portable if all you want to do is load and run some code. For sheer upload speed Coolsnaz2's high speed synchronous serial uploader system is still king, but ideally you need to have SCIOS 3 in which the cassette tape routines have been replaced by cs2's fast loader code to get the best out of that loading system. |
15th Mar 2023, 10:52 am | #49 | |
Pentode
Join Date: Nov 2022
Location: Chesham, Buckinghamshire, UK.
Posts: 135
|
Re: SoC Mk14 Pico Uploader
Quote:
I will try to get the supporting documentation updated this week. I have also added a setup for the old system software that I will share once I have tested it . I would be interested in feedback on the upload speeds currently I have settings for 4.7Mhz,4Mhz and very slow (for debug), should I include one that is a bit faster but still slow enough to work when a VDU interface is operating ? |
|
15th Mar 2023, 12:36 pm | #50 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: SoC Mk14 Pico Uploader
As mentioned before the four most likely 'speed' scenarios are, in order of the maximum speed the uploader can run at (fastest to slowest).
-Standalone system operating at 4.43MHz (most original MK14s). -Standalone system operating at 4.00MHz (original MK14s which at some point had a VDU attached, or most modern replicas). -4.43MHz system being slowed down by an active, attached VDU. -4.00MHz system being slowed down by an active, attached VDU. You may argue whether there is really a specific need to cater for the 4.43MHz case because even when throttled back a bit to the maximum reliable upload speed for a standalone 4.00MHz system, it's still quite fast. Coolsnaz2's serial uploader takes the pragmatic view that there really isn't a specific need and sends the serial data only just slowly enough that a 4.00MHz system can keep up with it, and so a slightly faster 4.43MHz system will also have no trouble dealing with it as well. When there is a VDU connected and active that does cause a significant system slowdown which means that your (and my) uploader have to 'press' the keys for a little bit longer to ensure that they are reliably read because the system scans the keypad more slowly than it normally does. You could say, then, that you really only need two upload speeds, one for 'no VDU' and one for 'with VDU', with the 'no VDU' timing values adjusted to the smallest which will reliably work with a standalone 4.00MHz machine and the 'with VDU' timing values adjusted to the smallest which will reliably work with a 4.00MHz system + active VDU. As the code is easily read and the values easily modified, the would-be-overclockers among us, those who absolutely have to have everything going as fast as it possibly can, can 'tune' the values to suit their own specific use case, should they so wish. The code for tracking and managing the addresses in non-continuous code - I don't think I even understand that myself now. My original uploader (2012) just read the address from each line, changed to address entry mode, entered the address, changed to data entry mode and then typed in the data, but that was causing an extra six keypresses per Intel Hex line on most lines and had an unnecessary impact on the overall upload time. For the current version, as you've seen, I kept a running record of the last address which code had been entered into and if the address of the first byte in the next line was equal to [that address+1], then I just kept on entering the data, and only broke out of that mode of entry if the address of the first byte in the current line was NOT equal to [that address+1]. |
15th Mar 2023, 12:56 pm | #51 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: SoC Mk14 Pico Uploader
When I thought I had a problem with the interface (which it turned out I didn't) I didn't find the slow debug speed especially useful because it was still too fast to really see what was going on.
As I mentioned I temporarily rigged the code to press just one single key over and over again in order to see whether the correct opto pair to press that key was in fact being activated, and some kind of menu-selectable 'test mode' which does that might be more useful. |