EMS/EMT files - what are they?

Started by JonB, 20:14, 06 January 17

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.



I read somewhere that the EMS/EMT file supplied with CP/M Plus is archive of some sort. Is that correct, and if so, how can I read its contents?



No, not an 'archive' in the usual meaning of the word.

They are in effect an executable file, which contains a number of separate components.   The program runs, and proceeds to place it's various component parts in their required places, which includes accessing the various memory banks.  Within John Elliott's pages, there is probably some detail as to the process.   Having completed the load, the program will then restore the default memory bank and pass control to standard CP/M 3.

I don't know if there is any 'rule' to the division into the component parts, as the sizes of at least some of the parts will change as the versions change.   Maybe not by much?   If you inspect the hex dump of the file, you can spot some of the likely divisions from null bytes leading up to a probable block boundary.  Also, certain text elements will betray the BIOS, the BDOS and the CCP, although these are not necessarily single lumps as they may be spread between swapped banks.   General information about the memory arrangement between banks of the complete CP/M will give some further hints as to the division.   I would expect also that the program itself knows exactly what the size of each lump is, and where it goes.   There may be a table of some sort?

Were you looking for specific components?   For some reason?

The division between EMS and EMT would seem to be somewhat arbitrary.   I think the file naming convention used had a limit, and when it became necessary to re-use certain names, the new variant became .EMT rather than .EMS - again, John's web page includes a listing of all the known variants/version numbers so you can see what was happening.



Ah, ok.

It's about the driver files (FIDs), and how you tell CP/M to load them. I got it into my head from using John's CP/M implementation on the PCW16 that it was an archive.

So I have much to learn. I think I understand the FID file structure and how to build it. The interface to the OS as described in John's pages is clear enough (plus there are some examples) although I am sure there is stuff not explained yet that I will need to know.

I have some questions, like how does one get CP/M to load your FID? And how can you test a FID? Is there any "official documentation on the FID interface to theOS?

Any ideas, or other resources you can point me to?



You need to use a version of CP/M (or Locoscript) that knows about FID files.   Then, as it loads, it looks for any FID file and if one is there, it loads it.

Such a version understands about such files, and is capable of applying a 'patch' to itself.   There is info there, I think again on one (or more) of JE's pages, detailing this.   Another one of his pages lists the history of the CP/M versions, indicating at what point they became sensitive to FID files (initially it was for different drive configs, and printers?, then for adding HDs, but could be for just about anything.

Not sure if there can be multiple items.

I have at least one version of CP/M that will work.   One is I think 2.9 - that's the version I use on Joyce when I want to activate the FID file I sent you about using direct HD access.   Very handy, but does cause a problem elsewhere so I don't use it unless I need to.   Just a performance issue, if I remember correctly.

I don't think there's any way you can 'test' such a file, just have to do it and see what happens?   You may get some sort of message if it doesn't install correctly, and the thing is disregarded?



I take it it was you 'JonB' asking about assemblers on the vcfed forum?

I assume you've got the DR assemblers, but don't like the intel mnemonics.

BUT, seems you DO need to use the DR LINK.COM to generate the correct format of PRL file (to be renamed as .FID) as per JE's instructions.

Have you tried to use the M80 assembler (MS) which - with the Z80 instruction at the top - will use the zilog mnemonics I think you prefer?   The M80 will produce the standard intermediate file (is it .REL), and I believe it's the same format as LINK needs.

So you could use the MS assembler, the DR linker, and you're OK?

Depending on your test code - the header could well - correctly - be empty.   Maybe there's nothing there that might be subject to being re-located?   I guess the system isn't clever enough to discard the header if there's no need for it??

I've got the M80/L80 system, also something called Z80ASM, also the HiSoft assembler, but I don't think the others would be useful for creating the .PRL/.FID??



Yep, it's me.

PASMO can create a PRL.. I am experimenting with it right now.

The main problem with developing on the machine is text editing. WS is too cumbersome, and there is nothing with vi keybindings (my editor of choice). Plus, it's handy being able to scroll quickly (as I do in Norepad++).

I will try M80/LINK.




Regarding the text editing - I really like the ED80 that comes with some of the HiSoft packages.

It's small, and fairly fast, and _ if I remember correctly, you can redefine all the keys as you see fit, creating your own config file to suit your own taste.   I assume therefore you could make it operate like vi?  If that's what you want.   The default is pretty much WordStar.  Which is fine for me.

It does not do what WS does, in allowing you to edit a file much bigger than memory, but then, if you need to do that, you might as well use WS!   But as the .COM is pretty small, you've got 40k+ to play with anyway.



Regarding the testing...

Some of the other little .FID files I have relate to setting different disk drives for - say - the 9512+ which may or may not have 3.5" drives fitted, or a 3" drive as B:, so there are I think 3 different tiny .FIDs each for one option.   At the moment of the file loading, a short message is displayed, the text is inside the .FID

So, if you're experimenting, I would suggest you include a succession of similar text messages for each step of your process, so you can confirm how far the process is getting.   Then, once things are OK, those messages can be removed.   Might be a BIT of a help?



Yes, thanks.

My FID should print a sign on message and exit, but it is doing nothing. Early days, though, I have lots of stuff to try.


I was saying in a previous post about ED80.

Just checked, the Free memory on startup is actually 53,754 - that's more than I remembered.


Powered by SMFPacks Menu Editor Mod