Yet another MK14 tape interface (ESP32).

[SiriusHardware]

Every time you do something like this, I just have to shake my head in amazement.

If you are absolutely confident that your OS version 3 code is 100% I can program it into one of my spare pairs of N82S131N PROMs, PM me about that. Others here have the ability to program the Tesla MH74S571 types, which I currently don't.

Unfortunately I don't have the ESP32 hardware required to run your loading system but maybe Realtime, who does, has the means to place substitute PROMs into his system so he can independently test it before you commit it to PROMs.

[Realtime]

Coolsnaz2, that's quite an achievement - 63 bytes!!

So based on what you sent me previously I've created SCIOS_HL, a modified SCIOSv2 binary that includes the BL12 Intel Hex file loader. The loader replaces the original Tape Load and Tape Save routines (0x0052 - 0x0091) and now has an entry point of 0x0059.

I've blown that into an EPROM hosted on a modified RealView and I'm happily loading and auto executing hex files.

I've attached SCIOS_HL.bin and a diagram showing the ESP32 set-up.

I don't have an assembly listing for SCIOSv2, but if anyone can provide it I will update it with the Hex Loader code.

[SiriusHardware]

Thanks for that, Realtime.

Coolsnaz2, what did you have to overwrite in the end, just the cassette routines, or...?

[coolsnaz2]

SiriusHardware: Yes, just the cassette routines with 2 bytes spare.

Mark1960: Files attached as requested, unfortunately fast loader only currently works with ESP32 web server.

The web server sends the following to the MK14 for each line of the HEX file:-

Length = 1 byte the Length is changed to zero at the End Of File
Load/Execute Address = 2 bytes
Data = 1 to 16 bytes

[SiriusHardware]

If I can just clarify that, do you mean that the webserver sends the code to the MK14 as raw binary bytes (not ASCII Hex or Intel Hex), so that a typical line would be

10h 0Fh 12h 00h 01h 02h 03h 04h 05h 06h 07h 08h 09h 0Ah 0Bh 0Ch 0Dh 0Eh 0Fh

A line signifying 'end of file' starts with a length value of 00h, and presumably only contains two further bytes to be treated as the execution address rather than the load address?

If this is the exact protocol 'syntax' expected by the fast loader code then it should hopefully be possible to send code to the MK14 from almost any source which can generate that protocol from two pins of an I/O or user port, whether it be an Arduino, a BBC B or even a Commodore PET for example.

How is the loader actually invoked? (what is the execution address of the loader code on the MK14?)

[SiriusHardware]

Too late to edit the above again: I see that Realtime has already stated the loader execution address as 0059h.

Realtime, I think someone, somewhere around here did reconstruct the 'new' OS as SBASM source code - unfortunately I can't find it but you may be more determined than I am.

[ortek_service]

Originally Posted by SiriusHardware

>>
>>
How is the loader actually invoked? (what is the execution address of the loader code on the MK14?)

It seemed to me that the execution address of the loader code was 0x0059, from what was previously posted by Realtime - as copied below

Originally Posted by Realtime

So based on what you sent me previously I've created SCIOS_HL, a modified SCIOSv2 binary that includes the BL12 Intel Hex file loader. The loader replaces the original Tape Load and Tape Save routines (0x0052 - 0x0091) and now has an entry point of 0x0059.
>>
>>

[SiriusHardware]

Yes, see #146 above. I must try to keep up.

[ortek_service]

Originally Posted by SiriusHardware

>>

Realtime, I think someone, somewhere around here did reconstruct the 'new' OS as SBASM source code - unfortunately I can't find it but you may be more determined than I am.

It recall Chris Oddy has done this, and seems to be available around half-way down his webpage - At end of files under the Firmware heading:

http://www.theoddys.com/acorn/Acorn%...MK14/mk14.html

[Realtime]

Originally Posted by ortek_service

... Chris Oddy has done this ....
http://www.theoddys.com/acorn/Acorn%...MK14/mk14.html

Thanks. Of course, I should have thought of Chris' site. I'll make the updates and post in due course.

[coolsnaz2]

SiriusHardware : You are correct in the transfer protocol, data is sent out as raw binary to the MK14 SIN, and synchronization is achieved by sending timing pulses to the MK14 on Sense B.

I have updated the code slightly so that the execution address is the same as the load address, 0x0052 if put into SCIOSv2. The code in asm is easier to read, and the code is exactly the same size as the code it is replacing. So the execution address will change from 0x0059 to 0x0052, which was the original Store To Tape address.

[SiriusHardware]

Change of execution address noted.

One further question about the transfer protocol - how does it indicate or handle a file with no execution address embedded?

(Sometimes files are just data, like an image file intended to be loaded directly into VDU screen memory, or sometimes they contain executable code which is not intended to be run standalone, like the various subroutines in the manual).

Edit: Just thought of another one: Is the data clocked on the rising edge or falling edge of the clock signal to Sense-B? I would guess rising, but prefer not to guess.

[TonyDuell]

Give the file an execution address of 0001, which will restart the monitor (like pressing Reset)?

[SiriusHardware]

Excellent idea, but that would mean one extra layer of customisation only for the Intel Hex files intended to be loaded by this project.

Certainly if the current loader code does not anticipate files without an execution address, that is the way to deal with it.

[SiriusHardware]

that would mean one extra layer of customisation only for the Intel Hex files

No, what am I talking about - 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.

No further change required to the MK14 fast loader code or the Intel Hex file, only to the utility which reads the Intel Hex file and converts it to the simplified raw binary protocol required by the fast loader code. Maybe Coolsnaz2's version of the webserver code already does this?

[SiriusHardware]

If doing the jump to 0001 at low level then it may actually need to be a jump to 0000h because the SC/MP pre-increments the Program Counter before fetching the instruction (which is why the OS code starts at address 0001h and not 0000h)

[Mark1960]

Coolsnaz2’s fast loader already makes that adjustment to the execution address.

[SiriusHardware]

OK, so then if no execution address found at FFFE/FFFF in the file, the webserver / other host utility program should send the MK14 an 'end of file' line with execution address = 0001h which the MK14 resident fast loader code will then adjust to 0000h, which the SC/MP will then increment back to 0001h...

[coolsnaz2]

SiriusHardware: Is the data clocked on the rising edge or falling edge of the clock signal to Sense-B? I would guess rising, but prefer not to guess.

I had to double check the MK14 code, the Serial Input is read when Sense-B goes high, therefore rising. See attached photo supplied by Realtime.

SiriusHardware: One further question about the transfer protocol - how does it indicate or handle a file with no execution address embedded?

Currently the web server looks for the character 'F' in position 4 of a line to decide EOF has been reached and to send out 0x00 and execution address. If you send over a couple of example files with just data, I will update code to send execution address of 0001h.

[SiriusHardware]

Acknowledged, I am at work just now but will have a look later.

It's not just data files though, it can also be a file containing executable code which for whatever reason you do not want to automatically run after loading. Any Intel Hex file which does not include data at addresses FFFE/FFFF in other words.