Added cpct_loadBinaryFile and cpct_enableBackgroundROMs functions

[nestornillo]

This PR tries to implement Kevin Thacker's contributed routine for binary loading from Issue #50

[nestornillo]

cpct_loadBinaryFile
I've supposed the intention for this function is to read from disc and not tape (comment on line 53 "two k buffer not used with cas in direct" suggests that), so I've focused on disc. It can read from tape, but then it uses the 2k buffer and shows loading messages on screen.

I've mixed issue #50 code with Kevin's code at http://cpctech.cpc-live.com/source/loader.html, and I've used some explanations and structure from Mochilote at http://www.cpcmania.com/Docs/Programming/Files.htm

Reading from disc means that disc ROM must be enabled again, so I've added cpct_enableBackgroundROMs. This enabling routine is a bit 'problematic' as it calls to mc_start_program, which resets the stack.
I'm thinking that the mc_start_program call maybe could be avoided, if initial DE and HL are preserved for kl_rom_walk,
but I left the calling because I think it might be needed when using non-amstrad roms, I'm not sure on that.
Also, Using ParaDOS (or other roms, i suppose) shows a boot message on screen when cpct_enableBackgroundROMs is called.
My knowledge about firmware is very small, so:
What do yo think of those caveats?
Should the enabling of disc ROM be done in a different way? (I've seen somewhere an example that tries to activate only roms 6 and 7)
My simple tests run fine, but does this function needs specific testings?

[lronaldo]

I see what you mean, @nestornillo. I think you have done a nice job by tracking Kevin's routines, understanding them and adapting them to CPCtelera.

With respect to the routines, loadFile is well done. I don't know at this time if it should be reviewed to test for cassete or disc or controlling other things, but it is usable and well done at its present state. The problem is with enableBackgroundROMs. This function is inadequate for general CPCtelera users as a way to load disc files at any moment in their execution (say to load a level). This is only okay to be used at the start of the program, and with some reserves. This routine loops through all connected ROMs from 0 to 7 and calls their INIT functions. This will cause this ROMs to modify RAM, saving space for their variables and overwritting things (that's what INIT is for, to set up initial values in RAM). Clearly, users won't like that :).

In fact, for load to work the only required thing is to reenable firmware, in general, if the user respects disc RAM values that would have been inited during boot. This is the same as calling the KL_ROM_WALK at the start and then ensuring not to overwrite disc RAM values. But, of course, firmware needs to be operating.

In any case, what we really need is a way to initialize DISC controller only. Preferably, if possible, finding a way to tell the controller which RAM to use for its values. Then reading the file, then closing and discarding ROM.

I'm going to ask some people that know this part of the firmware better for help. I think that's the proper way for the user.

Thanks again for all your efforts :)

[nestornillo]

Yes, enableBackgroundROMs is not nice. I just adapted the code I mention in previous comment, but I agree that it would be better if only disc ROM has to be enabled (rom 7 as I understand).
Let's hope someone with better knowledge of firmware can help, as I think reading from disc in CPCtelera would be very cool.