Yet another MK14 tape interface (ESP32).

[Mark1960]

Should that be any data file that does not contain data between F000 and FFFF, as only the most significant nibble is tested?

[SiriusHardware]

Just a point of order, the scope trace you included with #159 actually looks as though the clock is falling in mid-bit rather than rising in mid-bit, so maybe you could take another look at that and let me know?

(Normally if you are 'reading' synchronous serial data you do it in mid-bit rather than near the edge of the bit, so you do the 'read' on whichever edge of the clock - falling or rising - coincides with the centre of the bit).

So, some files which do not contain an execution address at FFFE-FFFF...

1) kdtest.hex, this is a test routine which, whenever a single key is held down on the MK14 keyboard, displays the row and column at the intersection of which the keypress was detected, and a symbolic representation of the key which should be at that row / column intersection. Load address is 0F12, but you have to manually run it from 0F20 after loading.

2) 2 x 512-byte image files which are intended to load (one at a time) directly into screen RAM at 0200h, assuming this RAM area is present and there is a VDU connected to display it (So, RealView set to display 0200-03FF for example). These are data-only and not intended to be executed.

[SiriusHardware]

Should that be any data file that does not contain data between F000 and FFFF, as only the most significant nibble is tested?

On a 'normal' MK14 there is no RAM anywhere in the range Fxxx and so Coolsnaz's method of checking just one character, the most significant of four should be OK but people keep talking about adding bits to expand the RAM further - the question is will there ever be RAM in the range Fxxx, because if there might be then the uploader should really look for the full FFFE start address (so check the fourth, fifth, sixth and seventh character of the file, and only if they are F, F, F, E should the uploader interpret the bytes at FFFE and FFFF in the file as an execution address). The original Pi-Uploader does look for the whole address, not just the most significant digit.

Anywhere else in the Fxxx range could one day be valid RAM.

[Mark1960]

Even with expanded memory I was planning to use F000-FFFF as memory mapped IO but as that part of Coolsnaz’s code is on the server it may be worth considering as its not subject to the MK14 memory limit.

I was looking at the possibility of modifying the fastloader to use normal serial protocol, connecting sense B to serial in to detect the start bit. Looks like it removes 5 bytes and adds at least 6. Two bytes to delay from the start bit to the middle of the first data bit, relying on accumulator containing 20 after start bit detected, then four bytes to delay between the centre of each bit. It would be quite a lot slower, but use a standard usb to ttl serial adapter from the pc. There would also need to be a python script on the pc to format the data from the hex file.

[SiriusHardware]

I think the main USP of Coolsnaz's methodology is its blistering speed, it's easier to crank the speed right up to whatever the highest speed the lowest common denominator (the SC/MP in this case) can cope with when using synchronous (data + clock) serial data as he is.

If using asynchronous serial, assuming you would want to adhere to a standard baud rate you also run into the 4.00Mhz / 4.43MHz problem, where the timing values would need to be adjusted accordingly for one clock frequency or the other unless you were using a very low baud rate in which case you might get away with setting the MK14 baud rate at a half way value between the ideal values for 4.00Mhz and 4.43MHz.

There is already an existing USB Serial Hex to MK14 programming interface here -

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

- needs a bit more hardware of course, but on the other hand requires no modification to the OS PROMs and the host machine with the code on it only needs to have a native terminal program capable of sending text to a USB serial port.

This will shortly be joined by DavidMS's functionally similar Pi Pico based version which also has an onboard display / UI so that 'popular' software can be stored on the interface and sent from there to the MK14 without the need for a host PC.

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

[Realtime]

Originally Posted by SiriusHardware

2) 2 x 512-byte image files which are intended to load (one at a time) directly into screen RAM at 0200h, assuming this RAM area is present and there is a VDU connected to display it (So, RealView set to display 0200-03FF for example). These are data-only and not intended to be executed.

So I've added the following as the 2nd to last line of each .hex file

:02FFFE00000001

This sets the exec address to 0x0000 and therefore returns to the monitor and halts after loading (pretty much as as TonyDuell suggested) - resulting in the attached. This is the ESP32 web server and BL14 fast loader built into the SCIOS.

Nicely demonstrates the speed of the loader

[SiriusHardware]

That was basically Tony's suggestion and it is proof of concept but it means we then need a further specially modified form of hex file for Coolsnaz2's uploader, at least for non-autorunning files.

It would be better if, if possible, the uploader just recognises when the file does NOT contain an autorun address and then automatically sends the last line as 00 00 01 (End of file, run from 0001h) rather than having to specially modify the hex file.

This will give the fast-uploader the ability to use the many already existing hex files without any modification to the hex files.

[coolsnaz2]

SiriusHardware: (Normally if you are 'reading' synchronous serial data you do it in mid-bit rather than near the edge of the bit, so you do the 'read' on whichever edge of the clock - falling or rising - coincides with the centre of the bit).

The sync pulse has been delayed to coincide with the centre of each bit, see attached oscilloscope photo. We now have a 360 microsecond delay between each byte to allow the MK14 to process the byte, even with the VDU enabled. The current speed being achieved is approximately 2400 bps.

SiriusHardware: the uploader should really look for the full FFFE start address

The web Server has been updated to check for the full FFFE Start address and also sends 0001h if no execution address is found in the hex file.

The attached updated SCIOS binary file has been created by Realtime, and verified by myself.

[SiriusHardware]

Thanks for doing the 'no run address found' mod - it just made better sense for your loader to be able to work with all of the existing 'library' of programs, subroutines and purely data files without having to modify any of them.

That scope capture now looks like the rising edge of the clock is in the middle of the bit - I don't think there is any 'right' way to do it as long as the sender and the receiver both observe the same clock 'polarity'.

If you are happy that this is the final version, do you want to commit the modified OS - we'll call it MK14 OS V3 - to a pair of PROMs?

[Realtime]

I've been using MK14 OS V3 for almost a week now (code development and fast downloads) and can confirm that I haven't seen any issues with the fast loader or the original remaining parts of the OS. So IMO I think you're safe to blow the PROMs (mine is resident in EPROM)

[SiriusHardware]

I'm away from the Batcave for a couple of days so I can't do anything just now. To be honest I have been hanging back a bit while a few more tweaks were obviously being done, but it seems you and Coolsnaz2 have now arrived at what you consider to be the official release. Can I take it that the version posted in #168 remains the current version, there is no newer version?

[ScottishColin]

I know it might be a bit of a PITA, but something to preserve this for the future might be useful - perhaps a GitHub repository?

Colin.

[SiriusHardware]

I'm assuming that there is no 'timing' as such in the MK14-side code, as it probably just polls the serial clock input and reads the next data bit whenever the clock changes state from low to high. In that sense it is the sender which controls the upload speed, as long as it does not send so fast that the MK14 is still dealing with the last bit when the next bit is sent, so there will be an upper speed limit which the sender should not exceed. This will also have to be dialled down a little bit (as has been stated) to allow for the the system slowdown when an active VDU is connected.

I can't imagine that a clock speed of 4.00MHz or 4.43MHz will make much difference except that a machine with a 4.43MHz clock could read the code in at a slightly higher maximum speed.

We could potentially make the sender configurable so that it can send at one of four optimised speeds to suit:-

4.43MHz machine without VDU.
4.43MHz machine with VDU active.
4.00MHz machine without VDU.
4.00MHz machine with VDU active.

Currently, the webserver sounds as though it is throttled back for the benefit of the last / slowest case above - but it is still so much faster than any other current loading method that the small speed increase which could be gained by optimisation for the actual system in use is hardly worth worrying about.

[coolsnaz2]

SiriusHardware: Can I take it that the version posted in #168 remains the current version, there is no newer version?

Yes I can confirm the zip file posted in #168 remains the current version. If anybody is interested I can post arduino web server code to this forum, even thou the code is functional I will be updating the code over the coming weeks. I currently have versions that run on a standard ESP32, M5Stack Atom and M5stickC Plus. As mentioned before the web server is based on the following https://www.youtube.com/watch?v=TmV6JAUtrvw

[Realtime]

Originally Posted by SiriusHardware

….. it is still so much faster than any other current loading method that the small speed increase which could be gained by optimisation for the actual system in use is hardly worth worrying about.

I agree. Having a single version of the web server code outweighs any benefits of optimising the transfer speed. The biggest improvement comes from having the MK14-end loader resident in PROM. Typically, I can assemble a new iteration of a large program (using SBASM), upload it to the web server (PC to ESP32) and load it to the MK14 (SCIOS v3) in less than 30 seconds. That’s fast and very comparable to using MAME for development.

[SiriusHardware]

I have a further tedious question about the MK14-side fast loader code. I understand that it uses several bytes of RAM to store its variables while working. Which bytes of RAM are they?

[Realtime]

Not tedious at all!

It uses the same 3 bytes of RAM that the original Tape Save routine uses - 0xFF8, 0xFF9, 0xFFA. The routine relies on P2 being zero, which it always is after a reset or power on.

[SiriusHardware]

That's an interesting bit of info in and of itself because it implies that if you had typed in valid code filling the entire 'original' user RAM from 0F12 - 0FFF then the very act of trying to save it to cassette would damage several bytes towards the end of the code. I hadn't previously considered that.

I presume this also means that any code you attempt to load in using the fast loader can't include code to be loaded in over 0FF8, 0FF9, 0FFA otherwise it will 'break' the operation of the loader in mid-load.

My question would be, are there another three RAM bytes which would be more suitable to use?

Looking at an MK14 fully populated with 640 bytes of onboard RAM the areas available for user code are:

0F12-0FFF - (0F00-0F11 are used by the monitor)
0B00-0BFF
0880-08FF

It could be better to re-use three of the OS 'system variable' bytes at 0F00-0F11 for the simple reason that most existing user code avoids using those locations and indeed any code originally written with keypad injection loaders in mind has to avoid that RAM area because they use the OS to facilitate the upload, therefore the uploader must not overwrite those bytes during the load process. If there is an actual need to place code at 0F00-0F11 it has to be loaded into 'spare' RAM such as the 8154 RAM and then block copied into 0F00-0F11 after control has been handed over to the user program.

This restriction does not apply to the fast-loader which is entirely independent of the OS. Once you enter the start address of the fast loader and press 'Go' the SC/MP is entirely under the control of the fast loader and the OS is not using those reserved bytes, so they are momentarily free for use by the fast loader.

After the code has fast loaded, the loader either hands control over to the loaded program if it is an auto-run program, or restarts the monitor which of course re-initialises the contents of 0F00-0F11, so as far as I can see these bytes would be 'safe' for the fast loader to use and would free up 0FF8, 0FF9, 0FFA for user code, giving an uninterrupted run of usable RAM from 0F12-0FFF.

[ortek_service]

Keeping the used-for-local-variables RAM within 0F00-0FFF does seem the most sensible alternative-option, as it also means that a 'standard' MK14 (without the extended 0B00-0BFF RAM or the 8154's 0880-08FF RAM fitted), would also still work with it - Even though there maybe not many programs that do need the extended-RAM at least.

And re-using ones already used by the SCIOS at the bottom of RAM would seem a good idea - It's strange that SoC / NS decided to use ones at the top of the original RAM as well, but I presume that's because Cassette interface was added later (In SCIOS v2?), so many programs were already starting just above monitor, at 0F12.

Although I wonder what 0FFB - 0FFF were used for - Presumably not vectors

BTW, I've just noticed an MK14 photo here, where it seems someone didn't cut their edge-connector down to match the numbers of ways on Exp. bus and left an over-hang! https://www.quora.com/Has-anybody-ma...chine-language

[Mark1960]

FF9-FFF are used to store users pointers and registers before and after calling users code. They are addressed using PC relative addressing from the low area of prom code to avoid using pointers as that would corrupt the user codes pointers. It seems the cassette loader was reusing the address for P1.