Football Manager

Include new and ported/converted games, and old games/tools. Subjects about CP/M software goes in the CP/M Forum.
acsi
Posts: 69
Joined: 16 May 2019 08:49

Football Manager

Post by acsi »

By any chance does anyone have a working copy or the holy grail of an original copy for sale?
Martin A
Posts: 802
Joined: 09 Nov 2013 21:03

Re: Football Manager

Post by Martin A »

Dave has a download of the MTX on his site.

http://primrosebank.net/computers/mtx/m ... are_dl.htm
acsi
Posts: 69
Joined: 16 May 2019 08:49

Re: Football Manager

Post by acsi »

OK it seems I must be doing something wrong trying to load it on my CFXII machine or my MFX machine as I just get a blue screen? I've just tried it in memu and it works fine.
Martin A
Posts: 802
Joined: 09 Nov 2013 21:03

Re: Football Manager

Post by Martin A »

USER MTX can deal with some single stage .MTX files. Anything that more than 1 block of data fails.

That's becasue memu can patch the "rom" where the first stage loader make the call to load the next block from tape. On real hardware you can't patch rom, so after the first stage takes over, the MTX sits there waiting for the tape to read in the next block .

Andy Key came up with a program that may solve that, by swapping out the rom for ram and loading some patches in strategisc positions.
http://www.nyangau.org/loadmtx/loadmtx.htm.

Program size is also an issue, an MTX500, with SDX only has around 21K of free space, and most games were written for the 500. IF they're biggher tham 21k that risks the disc code being trashed.

I had a look at the football manager MTX file and I think there's 4 blocks, and the code is 28k in size. The last two blocks look like they will be overwiting the disc handling code in high memory.
User avatar
gunrock
Posts: 248
Joined: 28 Oct 2020 21:17

Re: Football Manager

Post by gunrock »

Interesting point on the memory limitations, but surely with the MFX and CFXII the machine has been expanded to 64k (unless asci cheaped out on tricking out those beauties :lol: ).

So, I'm assuming it's because the game loads into the contiguous 32k starting at 8000h and basic/SDX disk routines shrink that 32k to 21k, thus 28k "doesn't fit" in a 64k machine?
Steve G
Danish Memotech MTX 512, MFX and loving it
acsi
Posts: 69
Joined: 16 May 2019 08:49

Re: Football Manager

Post by acsi »

Interesting and that explains a lot.
I have just tried on my MFX fitted 512 (yep full 64K on board unlike the CFXII one which only has 32K on the MB).
I had a try in menu first as per Andy's recommendation from his page. I got it to load the game properly on the second go which filled me with some hope. But alas on the MFX machine although sometimes I can get it to load the title screen it locks up from there.
I have used the LOADMTX program to successfully load Manic Miner however which is another one which was failing to load.

Thanks for your help

Now back to looking for the Holy Grail :lol: as for some reason that game is one I really enjoy.
Martin A
Posts: 802
Joined: 09 Nov 2013 21:03

Re: Football Manager

Post by Martin A »

gunrock wrote: 10 Nov 2023 12:13So, I'm assuming it's because the game loads into the contiguous 32k starting at 8000h and basic/SDX disk routines shrink that 32k to 21k, thus 28k "doesn't fit" in a 64k machine?
Pretty much spot on.

From my quick look at the MTX, Football manager's 2 game sections load from #8100 to #EFFF.

The disc code runs from #D700, that's a pretty hefty overlap.
stephen_usher
Posts: 326
Joined: 27 Nov 2016 19:58

Re: Football Manager

Post by stephen_usher »

I guess that the MFX could read each file into a high memory page as it has memory to spare.

I wonder if the code could then trace through the first loader program looking for access to the tape hardware or ROM routine and then redirecting that to a routine to copy the data from the correct memory page. Sounds a bit complicated and slow though.
User avatar
gunrock
Posts: 248
Joined: 28 Oct 2020 21:17

Re: Football Manager

Post by gunrock »

stephen_usher wrote: 10 Nov 2023 13:53 I guess that the MFX could read each file into a high memory page as it has memory to spare.

I wonder if the code could then trace through the first loader program looking for access to the tape hardware or ROM routine and then redirecting that to a routine to copy the data from the correct memory page. Sounds a bit complicated and slow though.
Not sure that would work Stephen, as (from memory) the GALs on the MFX only had enough room for the equations to map the extra RAM in RELCPMH=1 (i.e CP/M) mode, thus the extra memory isn't available in SDX Basic.

Martin or Dave can set me straight if I've misremembered or misunderstood the situation.

EDIT: Actually, went and checked myself ands I am indeed, wrong! There is 512K available in SDX Basic for both the base 32k or 64k system.
https://www.mtxworld.dk/memorum/search. ... sf=msgonly
Martin wrote: The MTX memory map in "ROM mode" has room for 16 pages of 32k and then 16k fixed memory. The MTX memory test has a bug if all 16 pages are full, and reports no paged ram found ram as a result. So MFX maps in 15 full pages and one half page. Since there is already some memory in that area it actually means, either 32k or 64k of the expansion RAM is unused. So either system has 512k in basic.
Steve G
Danish Memotech MTX 512, MFX and loving it
Martin A
Posts: 802
Joined: 09 Nov 2013 21:03

Re: Football Manager

Post by Martin A »

The Memotech 14L4 PAA devices were limited to 4 terms per pin. So the 512K SDX only made the ram available to CPM.

MFX on the other hand uses a much newer 22V10 and that allows 8 to 16 terms depending on the pin. so the full 512k is available in Basic as well as CPM. PEEK (64122) is 15. However that 512k is viewed through 32k wide windows. The largest single block you can load in basic mode is #4000 to #D6FF/ 37k or so. The football manager MTX is 41k.

One possible option I looked at before sticking to the most simplistive USER MFX code, was after loading a block, before returning to the caller code. USER MFX would scan the loaded block looking for the signature bytes that would indicate CALL #0AAE (CD AE 0A) and to patch them on the fly to call somehwere else.

There were problems with that though:
The 3 byte sequence CD AE 0A could just be data.
The 3 byte sequence could be in the middle of other code (JP/CALL #AECD, LD A,(BC) being the obvious ones)
Games that save their status to tape could legitimately use CALL #0AAE, there are't many but the level 9 Adventure series spring to mind.
Checking some of the loaders I found other code sequences than just CALL. JP #0AAE is quite often used for the last block.
Big blocks would still overwrite the disc handler code

It just got too complicated.
Post Reply