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.

Reply
 
Thread Tools
Old 23rd Jan 2023, 3:40 pm   #121
coolsnaz2
Tetrode
 
Join Date: Aug 2020
Location: Wallington, Greater London, UK.
Posts: 50
Default Re: Yet another MK14 tape interface (ESP32).

Quote:
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.
coolsnaz2 is offline   Reply With Quote
Old 23rd Jan 2023, 8:05 pm   #122
Realtime
Pentode
 
Join Date: Jan 2021
Location: Ashford, Kent, UK
Posts: 101
Default Re: Yet another MK14 tape interface (ESP32).

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.

Code:
		.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:

Code:
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.

Code:
: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
Realtime is offline   Reply With Quote
Old 24th Jan 2023, 12:04 am   #123
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 9,518
Default Re: Yet another MK14 tape interface (ESP32).

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.
SiriusHardware is offline   Reply With Quote
Old 24th Jan 2023, 7:44 pm   #124
coolsnaz2
Tetrode
 
Join Date: Aug 2020
Location: Wallington, Greater London, UK.
Posts: 50
Default Re: Yet another MK14 tape interface (ESP32).

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.
coolsnaz2 is offline   Reply With Quote
Old 24th Jan 2023, 8:12 pm   #125
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 9,518
Default Re: Yet another MK14 tape interface (ESP32).

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.

Last edited by SiriusHardware; 24th Jan 2023 at 8:27 pm.
SiriusHardware is offline   Reply With Quote
Old 24th Jan 2023, 8:48 pm   #126
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 9,518
Default Re: Yet another MK14 tape interface (ESP32).

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.
SiriusHardware is offline   Reply With Quote
Old 24th Jan 2023, 10:06 pm   #127
Mark1960
Heptode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 981
Default Re: Yet another MK14 tape interface (ESP32).

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.
Mark1960 is offline   Reply With Quote
Old 24th Jan 2023, 10:28 pm   #128
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 9,518
Default Re: Yet another MK14 tape interface (ESP32).

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?
SiriusHardware is offline   Reply With Quote
Old 25th Jan 2023, 1:56 am   #129
Mark1960
Heptode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 981
Default Re: Yet another MK14 tape interface (ESP32).

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.
Mark1960 is offline   Reply With Quote
Old 25th Jan 2023, 8:18 am   #130
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 9,518
Default Re: Yet another MK14 tape interface (ESP32).

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.
SiriusHardware is offline   Reply With Quote
Old 29th Jan 2023, 8:08 pm   #131
coolsnaz2
Tetrode
 
Join Date: Aug 2020
Location: Wallington, Greater London, UK.
Posts: 50
Default Re: Yet another MK14 tape interface (ESP32).

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
Attached Files
File Type: txt BL9.txt (1.6 KB, 2 views)
coolsnaz2 is offline   Reply With Quote
Old 30th Jan 2023, 6:11 pm   #132
Realtime
Pentode
 
Join Date: Jan 2021
Location: Ashford, Kent, UK
Posts: 101
Default Re: Yet another MK14 tape interface (ESP32).

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.
Realtime is offline   Reply With Quote
Old Yesterday, 12:41 pm   #133
ScottishColin
Octode
 
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,051
Default Re: Yet another MK14 tape interface (ESP32).

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.


Quote:
Originally Posted by coolsnaz2 View Post
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
ScottishColin is online now   Reply With Quote
Old Yesterday, 5:15 pm   #134
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 9,518
Default Re: Yet another MK14 tape interface (ESP32).

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.

Quote:
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.
SiriusHardware is offline   Reply With Quote
Old Yesterday, 7:08 pm   #135
Mark1960
Heptode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 981
Default Re: Yet another MK14 tape interface (ESP32).

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.
Mark1960 is offline   Reply With Quote
Old Yesterday, 8:17 pm   #136
Realtime
Pentode
 
Join Date: Jan 2021
Location: Ashford, Kent, UK
Posts: 101
Default Re: Yet another MK14 tape interface (ESP32).

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
Realtime is offline   Reply With Quote
Old Yesterday, 9:18 pm   #137
Phil__G
Hexode
 
Join Date: Mar 2011
Location: North Yorkshire, UK.
Posts: 431
Default Re: Yet another MK14 tape interface (ESP32).

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

Last edited by Phil__G; Yesterday at 9:24 pm.
Phil__G is online now   Reply With Quote
Old Today, 11:10 am   #138
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 9,518
Default Re: Yet another MK14 tape interface (ESP32).

Quote:
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.
SiriusHardware is offline   Reply With Quote
Reply

Thread Tools



All times are GMT. The time now is 12:54 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 - 2023, vBulletin Solutions, Inc.
Copyright ©2002 - 2023, Paul Stenning.