View Single Post
Old 14th Jan 2021, 12:42 am   #80
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,556
Default Re: MK14 Tape Interface

I suppose the value of this audio feature depends on how you think or how you mean the program to be used. If it's used to create tapes by playing the file it creates out to an actual tape recorder then it will be useful and the 'format' of the audio labelling of the file will be consistent - the only problem I can see is in getting it to say the name of the program which is being saved, like 'duck' or 'moon', can your method stretch to that?

If the main purpose of the utility is to create files which can be played out from digital devices then the spoken header is less useful and having the load and execution addresses embedded in the file name is the most useful aspect.

With regard to handling split addresses, there are a few scenarios to consider:

1) A hex file with split blocks in the same 256-byte block of memory with a gap separating them. (Example: 'Message'). In this scenario the best approach would be to pad the empty space between the blocks with some byte value like 00 and then output the first block, the padding, and the second block as one audio file, similar to the way John (JBH's) program for the Gemini does it.

2) A hex file with split blocks which reside in different 256-byte blocks of memory.
(Example: 'Onearm'). In this case the program will have to output two separate cassette data files.

Reject files where
-There are more than 256 bytes in one continuous run
-A code block straddles a page boundary
-The addresses in two blocks of code overlap

In otherwise valid files, discard any code blocks with an address which does not exist on the MK14 (but do allow code which is designed to go into the range 0200-07FF since it is possible to map extra RAM into that area)
SiriusHardware is offline