Yet another MK14 tape interface (ESP32).

[coolsnaz2]

and all with 8154's

Yes Phil__G, and being used for the fast loader program, and sound on the Invaders2 program.

Forum member’s help required.

I am just trying to sort out the execution address in the ESP32 MK14 web interface. In the M5Stack process I added the execution address manually to the end of the data transfer process. I now want to just use the hex files with no modifications. The Intel HEX document on Wikipedia mentions a record type of 05 (Start Linear Address) but none of our MK14 Hex files seem to use this record type. Most of the hex files seem to have the execution address placed in FFFE, so it makes sense to use this as the execution address.

[Realtime]

I've been playing with SBASM and have come up with the following:

In the assembler code I've defined the Execution Address by a label ENTRY (this is separate from the memory address where the code is loaded, but could be the same address). In the example here the code starts with a look-up table and is loaded to 0x400, but the entry point for execution is actually 0x048C.

		.DB 63,00,49,14,49,49,63,63,63,00  ; 
		.DB 63,14,49,14,49,49,63,49,63,14  ; 
		.DB 14,14,49,14,49,49,14,49,14,14  ; 
		.DB 00,00,14,14,14,49,00,63,00,00  ; 
		.DB 00,14,14,14,14,49,00,49,00,14  ; 
		.DB 32,37,32,27,28,31,32,27,36,31  ; 
		.DB 41,22,49,14,49,49,41,41,41,22  ; 
		.DB 41,22,49,22,49,41,41,41,41,22  ;
		.DB 22,22,41,22,41,41,22,41,22,22  ; 
		.DB 14,14,22,22,22,41,14,49,14,14  ;
		.DB 14,22,22,22,22,41,14,41,14,22  ; 
		.DB 32,37,32,27,28,31,32,27,36,31  ;
		.DB 30,55,34,59,32,57,34,55,30,59  ; 
		.DB 00,00,63,00,63,63,00,63,00,00  ;
		
ENTRY:	
;===============================================
; P2 is the variables pointer
;===============================================	
	LDI VAR/256
	XPAH	P2
	LDI	VAR\256
	XPAL	P2

At the end of the assembler I've added the following:

EXEC_ADR:
	.NO 0xFFFE
	.DB ENTRY/256
	.DB ENTRY\256

This places a record at the end of the .hex file with the execution address (0x048C) positioned at 0xFFFE, i.e.

:10079000D4209806C202E401CA0202C202980103F0
:1007A000C201D401CA02C2011DCA0102C2029801DB
:0707B00003C2001DCA003F57
:02FFFE00048C71  -------------------------This one!
:00000001FF

So you only need to decode the address field as being 0xFFFE, in the fast loader code, to determine that that record holds the the execution address. Of course it means genuine code cannot use 0xFFFE/F.

Hope that makes sense

[SiriusHardware]

This 'convention' of the execution address being held in file addresses FFFE/FFFF in a lot of our files is my fault unfortunately, when I was putting together the first Pi-Uploader I couldn't find anything concrete about Intel Hex file records and execution addresses so I decided to adopt the dodge whereby the uploader would watch out for code residing at FFFE/FFFF - not normally a real address on the MK14 - and would use those two bytes, if found, as the Hibyte / Lobyte of the execution address.

All the user then has to do is put a bit at the end of their source which defines those two bytes at those addresses, either as absolute byte values or as ones calculated from a label, as per the second bit of code in the previous post.

There is absolutely no reason why any other system should continue to use this method so if there is a clearly defined method of including an execution address in an Intel Hex file, by all means go with that from now on.

[coolsnaz2]

SiriusHardware

Thanks very much for the clarification, I have updated the ESP32 MK14 web server to use the address at FFFE as the execution address. I have manually updated the MAZE and Invaders2 to include the execution address and all MK14 examples load and execute correctly. I will try and create a YouTube video in the next few days showing ESP32 MK14 webserver in action.

[SiriusHardware]

I look forward to seeing that.

In the meantime has anyone noticed a way to specify an execution address for SBASM3 to include in the output file as an 'execution address' record?

If SBASM3 actually supports the generation of the correct type of record in an Intel Hex file I will consider adding it to the Pi-uploader (send14) script as an alternative way of specifying the execution address.

Edit: Looking at the list of SBASM3 directives here:-

https://www.sbprojects.net/sbasm/directives.php

I don't see any way to get SBASM3 to generate an execution address record (or 'linear start record') in its Intel Hex file output.

In any case the information given here

https://developer.arm.com/documentation/ka003292/latest

seems to imply that the type '05' record type only occurs in files targeting 'MDK-ARM only', whatever that means. The apparent lack of a universal / general way of specifying a 16-bit start address in a 'normal' Intel hex file may have been what led me to adopt the approach I did.

[SiriusHardware]

An adjustment to the above: Since the type '05' record is designed to contain a 32-bit address, it may be that we should only expect assemblers for 32-bit processors to produce Intel Hex files with type 05 records in them.

[Mark1960]

The ideal place to put the execution address would be the SoC target address, but thats not going to work when the loader is using the SoC monitor to load the data from the intel hex file to memory.

[SiriusHardware]

That is a limitation of keypad injection loaders like mine because they do use the OS to 'type in' the code, but not necessarily for Coolsnaz2 whose method is high speed synchronous serial download.

Not sure what you mean by the 'SoC target address', though?

[Mark1960]

I meant the address that is displayed by the monitor, the address that gets modified when you enter data or the execution address when you press G.

[SiriusHardware]

The thrust of the discussion over the past few posts was really more about where or how to place the execution address in a program file so that it can be recovered by an uploader and used to auto-run the program after loading. (For anyone not too familiar with the MK14, the execution address of a program is not always the first address in the file).

I would imagine that after recovering the execution address from the file Coolsnaz2's code jumps or otherwise redirects the SC/MP to the start address of the program without any involvement from the OS.

[coolsnaz2]

As mentioned above please see attached link to the YouTube video showing the ESP32 connected to the MK14.

Also attached is the fast loader program witch is currently loaded into address 0880 and executed at 0883.

Intel.hex files are uploaded to the ESP32 via a web interface, before being streamed to the MK14. The hex files can cover multiple memory pages and include the execution address as mentioned in previous posts.

The fastloader has to be loaded first at the original MK14 cassette tape speed, but subsequent uploads transfer at 2,000 BPS, with Invaders2 taking just over 5 seconds to load.



https://youtu.be/5zl0YeMS4FI

[Realtime]

Nice video Coolsnaz2 Thanks for sending me the code base for the fast hex loader and web server. It’s running on an Esp32 Devkit and it works great. It’s the first time I’ve been able to load files across memory blocks in one hit - previously resorted to loading multiple files. The web interface is easy to use (once I found out the IP address of the esp32). Been controlling it via a PC so far but will give it a go with my phone soon. Makes for a very compact loader solution. Well done.

Btw I’m going to modify the mk14 fast loader part (BL9.hex) to be resident in EPROM. That will make it even more usable.

[ScottishColin]

I recognise that beer-mat. I really must get on with building my MK14. I have a spare ESP32 as well so this looks like another good project for me.

Colin.

Originally Posted by coolsnaz2

As mentioned above please see attached link to the YouTube video showing the ESP32 connected to the MK14.

Also attached is the fast loader program witch is currently loaded into address 0880 and executed at 0883.

Intel.hex files are uploaded to the ESP32 via a web interface, before being streamed to the MK14. The hex files can cover multiple memory pages and include the execution address as mentioned in previous posts.

The fastloader has to be loaded first at the original MK14 cassette tape speed, but subsequent uploads transfer at 2,000 BPS, with Invaders2 taking just over 5 seconds to load.



https://youtu.be/5zl0YeMS4FI

[SiriusHardware]

Yes, I saw the coaster too: I'm quite fond of that 'logo' now, it's becoming the unofficial 'badge' of the MK14 which, being un-cased, never really had one.

Once again great work by Coolsnaz2, although I don't have the hardware to try it out on at the moment. Looks very impressive in the video though.

Originally Posted by Realtime

Btw I’m going to modify the mk14 fast loader part (BL9.hex) to be resident in EPROM.

If you can somehow shoehorn it into the original PROMs that would be great - the cassette save and load routines are redundant now that we can create the code on something else and shunt it across at high speed, the same probably goes for the single step and jump calculator code - they were all nice to have when the MK14 was the only 'computer' we owned but are probably not much needed in these days of assemblers and uploaders.

[Mark1960]

I never found the jump calculator to be usefull as its easier to count the bytes than to key the addresses into to MK14, but the single step is something that might be worth keeping and it might change a lot of entry points in the prom to be able to gain from its removal.

[Realtime]

The EPROM version of BL9 needs 105 bytes (plus 3 bytes of RAM for variables). From what I can see the MK14 V2 monitor listing uses 63 bytes for save and load routines. The OFFSET routine uses only 8 bytes. The single step handler only uses 6 bytes. So all in all not enough space for the hex loader. Maybe there are other routines that could be lost but I can't see anything obvious.

If anyone can come up with a hex loader needing only 71 bytes then we're in business

[Phil__G]

Ignoring the checksum is a common method of simplifying intel hex read, no need to accumulate the c/s as bytes are received and no need for the compare at every line end - and hence no need for error handling. Since the source is directly connected over a short cable, errors are most unlikely anyway

[SiriusHardware]

Originally Posted by Mark1960

the single step is something that might be worth keeping

My original issue II did have the single step hardware fitted for most of its life - on a small PCB, hand drawn with a DALO pen and hand drilled, those were the days, but when I revived my interest in the machine around the turn of the century I stripped it back down to almost its original configuration because the single step add-on dangling off to one side made the machine look untidy, and I was at the same time engaged in making the first RS232-hex to Keypad uploader so I felt that on-machine debugging tools weren't really going to be needed any more.

Nowadays the single step circuit could be made with the smallest SMD TTL ICs on a very small square PCB which could be discreetly stuck to the underside of the MK14 PCB.

We now have one or two emulators including the one in MAME if we just want to see how our code will react in response to a particular set of circumstances.

The single-step code in the new OS PROMs might take some unpicking, I agree, but one minor reward would be the freeing up of the Sense-A input which is currently tied up by the single-step code even when the single-step hardware is not connected.

However from what Realtime says, not even the elimination of all three routines from the new OS PROMs will free up enough PROM memory to transplant the speed loader code into.

[coolsnaz2]

SiriusHardware, after a number of iterations I managed to shoehorn the fast loader into 63 bytes plus 3 bytes of RAM, and will fit into the original cassette routines space without affecting any other routines.

Phil__G, the fast loader ignores the checksum, and as you mentioned the short cable connecting the MK14 to the ESP32 does not seem to produce any errors.

All I need now is a couple of version 3 OS PROMs, with the new fast loader installed, not sure who can produce them. I won’t update my original MK14, but will update my Issue VI board. The alternative would be to add an additional ROM to the MK14.

I still have some work to do on the ESP32 Web Server, and I am also looking at other ESP32 devices, the M5Stack Atom.

It would also be interesting if someone else could use the fast loader routine to send programs into the MK14.

[Mark1960]

I’ll need to connect a usb to serial connector to my ram expansion board but could probably try this by replacing the cassette loader in the battery backed ram copy of the monitor. Any chance you could upload an assembler or hex version of the fast loader with the origin set to replace the cassette loader?

Edit: maybe I wasn’t paying attention, does the fast loader work with a usb to serial adapter or does it need a special format?