UK Vintage Radio Repair and Restoration Powered By Google Custom Search Vintage Radio and TV Service Data

Go Back   UK Vintage Radio Repair and Restoration Discussion Forum > Specific Vintage Equipment > Vintage Computers

Notices

Vintage Computers Any vintage computer systems, calculators, video games etc., but with an emphasis on 1980s and earlier equipment.

Closed Thread
 
Thread Tools
Old 10th Mar 2023, 7:29 pm   #41
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,483
Default 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.
SiriusHardware is online now  
Old 10th Mar 2023, 8:20 pm   #42
DavidMS
Pentode
 
Join Date: Nov 2022
Location: Chesham, Buckinghamshire, UK.
Posts: 135
Default Re: SoC Mk14 Pico Uploader

Quote:
Originally Posted by SiriusHardware View Post
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'.
you do seem to be correct, let me have a look at it. I have got distracted trying to get ZEN to work on an old Elektor Z80 computer
DavidMS is offline  
Old 10th Mar 2023, 8:51 pm   #43
DavidMS
Pentode
 
Join Date: Nov 2022
Location: Chesham, Buckinghamshire, UK.
Posts: 135
Default Re: SoC Mk14 Pico Uploader

Quote:
Originally Posted by DavidMS View Post
Quote:
Originally Posted by SiriusHardware View Post
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'.
you do seem to be correct, let me have a look at it. I have got distracted trying to get ZEN to work on an old Elektor Z80 computer
Found the error sorry, try this.

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 ?
Attached Files
File Type: zip code.zip (5.6 KB, 15 views)
DavidMS is offline  
Old 10th Mar 2023, 9:04 pm   #44
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,483
Default 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.
SiriusHardware is online now  
Old 10th Mar 2023, 9:27 pm   #45
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,483
Default 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.
SiriusHardware is online now  
Old 10th Mar 2023, 10:00 pm   #46
DavidMS
Pentode
 
Join Date: Nov 2022
Location: Chesham, Buckinghamshire, UK.
Posts: 135
Default Re: SoC Mk14 Pico Uploader

Quote:
Originally Posted by SiriusHardware View Post
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.
Yes it was on my list but not a priority - as I struggled to see why you wouldn't upgrade the newer PROM version. I will add it when I have cleaned a few other bits up. I accidentally purchased a set of old PROMS a while back so I should be able to test it with my replica board
DavidMS is offline  
Old 11th Mar 2023, 1:10 am   #47
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,483
Default 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.
SiriusHardware is online now  
Old 15th Mar 2023, 1:10 am   #48
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,483
Default 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.
SiriusHardware is online now  
Old 15th Mar 2023, 10:52 am   #49
DavidMS
Pentode
 
Join Date: Nov 2022
Location: Chesham, Buckinghamshire, UK.
Posts: 135
Default Re: SoC Mk14 Pico Uploader

Quote:
Originally Posted by SiriusHardware View Post

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.
Thanks Sirius, I had the same problem with the moonlander file - there was a problem earlier with uploading non continuous intelhex files but that was down to me breaking part of your original code

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 ?
DavidMS is offline  
Old 15th Mar 2023, 12:36 pm   #50
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,483
Default 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].
SiriusHardware is online now  
Old 15th Mar 2023, 12:56 pm   #51
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,483
Default 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.
SiriusHardware is online now  
Closed Thread

Thread Tools



All times are GMT +1. The time now is 6:59 pm.


All information and advice on this forum is subject to the WARNING AND DISCLAIMER located at https://www.vintage-radio.net/rules.html.
Failure to heed this warning may result in death or serious injury to yourself and/or others.


Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Copyright ©2002 - 2023, Paul Stenning.