MTXLib

[Bill B]

I have started a new thread for this, so that I can have the first topic, which I can keep updated with any revisions, where they can be easily found.

This is a follow up of a request from Jim for an easy environment in which to develop programs for the MTX using C. In response I suggested using the Code::Blocks IDE, and developed an initial library, reproducing a number of the MTX BASIC commands.

The attached files are the latest version of this. For ease of maintenance I have split the installation into three parts. Create a top-level folder in which to do your MTX development, I suggest calling this MTX_Projects, and then unzip each of the attached files in this folder.

The three bundles are:

• MTXLib - This contains the library source, documentation and build scripts. The library has now been extended and includes:
  • The routines reproducing the BASIC commands.
  • Routines for reading and writing disk files. These routines only read or write whole 128-byte disk sectors. It would be possible for someone to write a C wrapper around these to read or write arbitrary length records.
  • Routines for searching for files, renaming or deleting them.
  • Routines for providing direct access to the VDP memory and registers.
  • Routines for handling CTC and VDP interrupts.
• MEMU - The Memotech emulator. This has been updated yet again. I found that when a RUN file was loaded from the command line, the disk system was not even initialised. On a real MTX, RUN files of course have to be read from disk.
• demo - The demo program has been extended to illustrate and test a representative sample of all the routines in MTXLib. Note that not everything has been tested.

Important Note: In extending the library I discovered an issue with the way SDCC links together the code and data parts of a program. As a result, to work around this, the instructions on how to configure Code::Blocks to compile the library and MTX programs have changed. If you have already installed and configured Code::Blocks, carefully read the documentation in MTXLib\docs\codeblocks.html and update your configuration accordingly.

Other than perhaps posting the code on GitHub I have no intention of doing any more work on this in the near future.

[gunrock]

Thanks Bill, sterling work.

I will take a look at this some time over the summer.

[gunrock]

Hi Bill,

Just got a little time to have a look at this. Firstly, thank you - this is really well put together.

I had a couple of slight incidents during the setup (Windows 11).

I let SDCC install itself to my hdd and it wanted to go into the C:\Program Files folder but I switched it to D:\Program Files (I try to keep my C: drive install minimal). This was detected by CodeBlocks perfectly well but trying to build MTXLib led to errors complaining about the SDCC binaries being missing, primarily objecting to the space in the path.

Normally here I try two things, surround in double quotes or drop back to DOS 8.3 file and directory names. The former didn't work, but did change the error messages. The latter was problematic as my D: drive lacked the DOS 8.3 name support (didn't know that was possible, tbh). This reenabled with:

Code: Select all

fsutil behavior set disable8dot3 <DriveLetter>: 0

It doesn't add the DOS short names to existing filesystem items, so I still had to rename D:\Program Files to something else, create a new directory D:\Program Files and cut/paste the contents from the old to the new. I could then set SDCC configuration in Codeblocks to D:\PROGRA~1\SDCC, which worked.

The only other thing, was the instructions referring to using git to update the library to the latest version, but there is no public git as far as I can see.

Anyway, I managed to build the demo and run it. Now I just have to examine the demo code and the library documentation and see what I can do with it.

Thanks again.

[Bill B]

Steve,

Thanks for the feedback. Spaces in a path name are a pain, need to make sure there are double quotes in all the right places.

I will have to check where I installed SDCC on my Windows 10 PC. Like you I normally avoid C, however since I was trying to make everything easy to use I probably accepted the default location in this case.

[gunrock]

Hi Bill,

So I went back to this and got Codeblocks to self-discover SDCC again, which finds the location in it's "long-names" form. And... this time, building code works as it should.

I definitely tried hitting to button to auto-locate before I wrote my post above (not sure what it the button name is, as I don't have my machine in front of me). I suspect it might be related to the lack of short-name support on the disk, as that's the only thing I changed. Now, I would remove short-name support and try it again, but as it warns about potential data-loss, etc. I'll just put it down to gremlins or user error on my part, instead.

[Bill B]

Steve,

Thanks for the feedback. I must admit I never found the time to go back and look at my Windows installation.

With regard to hosting on GitHub, my theory was that when I got bug reports it would be easier for me to just push updates to a repository, rather than having to create a new zip file and upload it to the forum. Since there have been no bug reports (yet), I have had no incentive to create the repository

[gunrock]

Installation difficulties (again). So I had a chance to have another go around at this, as I replaced my SSD in my machine.

So starting with a new, formatted SSD, I installed SDCC, Codeblocks and Python to my D: drive, in D:\Program FIles. When configuring Codeblocks, I came across similar (if not the same) issues as my first install. This is not MTXLib's problem, this is a Windows 11/Codeblocks issue I think.

I used the Codeblocks "Autodetect" feature to find the SDCC toolchain. This worked fine, it detected the executables fine and listed SDCC as found. However, there were three issues.

Problem #1

Not finding SDCC during a build. See:

Code: Select all

Project/Target: "demo - Release":
  The compiler's setup (Small Device C Compiler) is invalid, so Code::Blocks cannot find/run the compiler.
  Probably the toolchain path within the compiler options is not setup correctly?!
  Do you have a compiler installed?
Goto "Settings->Compiler...->Global compiler settings->Small Device C Compiler->Toolchain executables" and fix the compiler's setup.

Tried to run compiler executable '"D:\Program Files\SDCC"/bin/sdcc.exe', but failed!

Skipping...
Nothing to be done (all items are up-to-date).

Although it doesn't look like it, I believe this is related to the lack of 8.3 shortnames on the volume. This is defaulted to be off on NTFS volumes in WIndows 11, as it's a minor performance benefit. Now on my original drive, 8.3 shortnames were off for my volumes, however for this drive (maybe after a Windows update maybe), this drive has shortname support on a volume by volume basis:

Code: Select all

C:\Windows\System32>fsutil 8dot3name query D:
The volume state is: 0 (8dot3 name creation is ENABLED)
The registry state is: 2 (Per volume setting - the default)

Based on the above settings, 8dot3 name creation is ENABLED on "D:"

C:\Windows\System32>

It's switched on, so, what's the problem? Well, it seems that when it is switched on, it doesn't create shortnames for existing files and directories that have been created already:

Code: Select all

D:\>dir /x
 Volume in drive D is WINMAX2_DATA
 Volume Serial Number is A650-2C70

 Directory of D:\

14/01/2023  21:40    <DIR>                       Backup
15/01/2023  21:39    <DIR>          DELIVE~1     DeliveryOptimization
18/03/2023  17:56    <DIR>                       gee
14/01/2023  20:30    <DIR>                       memu
18/03/2023  17:18    <DIR>                       Program Files
20/02/2023  19:57    <DIR>                       Program Files (x86)
18/03/2023  17:22    <DIR>                       temp
14/01/2023  20:29    <DIR>                       Utils
15/01/2023  21:33    <DIR>          WINDOW~1     WindowsApps
07/01/2023  20:39    <DIR>          WINMAX~1     winmax-drivers
21/11/2022  21:23    <DIR>                       winmax-tools
               0 File(s)              0 bytes

The D:\Program Files has no shortname. So, I renamed this directory and created a new "Program Files" directory. Then copied the contents of the old directory over to the new one.

Code: Select all

D:\>dir /x
 Volume in drive D is WINMAX2_DATA
 Volume Serial Number is A650-2C70

 Directory of D:\

14/01/2023  21:40    <DIR>                       Backup
15/01/2023  21:39    <DIR>          DELIVE~1     DeliveryOptimization
18/03/2023  17:56    <DIR>                       gee
14/01/2023  20:30    <DIR>                       memu
18/03/2023  21:33    <DIR>          PROGRA~1     Program Files
20/02/2023  19:57    <DIR>                       Program Files (x86)
18/03/2023  17:22    <DIR>                       temp
14/01/2023  20:29    <DIR>                       Utils
15/01/2023  21:33    <DIR>          WINDOW~1     WindowsApps
07/01/2023  20:39    <DIR>          WINMAX~1     winmax-drivers
21/11/2022  21:23    <DIR>                       winmax-tools

You can see there is a shortname for "Program FIles" Then I went back to Codeblocks and autodected the toolchain again. The problem now moves to a new issue, the compiler is running but linking is failing.

Problem #2

Search directories are pointing to C:, thus builds fail. Both includes and linker settings were wrong, that's

Code: Select all

C:\Program FIles\sdcc\include
C:\Program Files\sdcc\lib 

See in the build logs:

Code: Select all

D:\gee\Python\Python311\python.exe ..\MTXLib\tools\sdlk.py -L"C:\Program Files\sdcc\lib" -o bin\demo.exe  --no-std-crt0 -mz80 --opt-code-speed  --no-std-crt0 -mz80 --std-sdcc11   --code-loc 0x8000 ../MTXLib/lib/crt0.rel  ..\MTXLib\lib\MTXLib.lib obj\main.rel obj\screen1.rel obj\screen2.rel obj\screen3.rel obj\screen4.rel obj\screen5.rel obj\screen6.rel obj\screen7.rel

Easily fixed. You have to switch to the "Search Directories" tab and set the "Compiler" and "Linker" directories correctly.

Problem #3

Python doesn't work although it has been installed.

Windows 11 has a directory called WindowsApps which is in the path and has Python 3 executables that starts up the Microsoft Appstore so you can install from there. I always get my installs from the source project as MS store builds usually lag the real deal.

Code: Select all

D:\>dir c:\Users\steph\AppData\Local\Microsoft\WindowsApps\py*
 Volume in drive C is WINMAX2_BOOT
 Volume Serial Number is 6649-A71A

 Directory of c:\Users\steph\AppData\Local\Microsoft\WindowsApps

28/01/2023  12:02                 0 python.exe
28/01/2023  12:02                 0 python3.exe
               2 File(s)              0 bytes
               0 Dir(s)  221,878,714,368 bytes free

So you have to move the Python path in your PATH variable in your environment vars, to be in front of this directory in the path (maybe you could remove it - who knows what WIndows magic might break, though). Easily done.

Hope this helps anyone who comes across similar problems on a Windows 11 setup. I think it's partly related to me choosing to put my installations on drive D: and also becuase of the lack of shortname support. Anyway, it might help someone in the future.

[gunrock]

Understanding Z80 interrupts in IM2

First things, first, just so I don't make a total arse of myself: Am I right that Andy's original MEMU documentation says that CTC channels 1 & 2 aren't emulated in counter mode. A cursory look at the source code for your version Bill, that looks like that is still the case.

From ctc.c, void ctc_advance (int adv), line 291:

Code: Select all

            else if ( ( channel == 1 ) || ( channel == 2 ) )
                {
                int clks = cnt13 / 13;
                int cntr = ( c->counter == 0 ) ? 0x100 : c->counter;
                int cons = ( c->constant == 0 ) ? 0x100 : c->constant;
                while ( clks > 0 )
                    {
                    if ( cntr <= clks )
                        {
                        clks -= cntr;
                        cntr = cons; /* Reload */
                        if ( ( c->control & CC_INTERRUPT ) && ( c->is == isNone ) )
                            {
                            c->is = isPending;
                            IF_CHAN(channel)
                                diag_message(DIAG_CTC_PENDING,
                                    "CTC interrupt pending on channel %d (counter)", channel);
                            ctc_int ();
                            }
                        }
                    else
                        {
                        cntr -= clks;
                        break;
                        }
                    }
                c->counter = (byte) cntr;
                }

Is that right? From my testing, setting a counter mode interrupt function for Channel 2, doesn't seem get called in MEMU.

Depending on answers to this, I may ask more foolish questions! If anyone wants to know why I want to use CTC Channel 2, the answer is: "no particular reason, I'm just fooling around".

Thanks in advance.

[Bill B]

[A cursory look at the source code for your version Bill, that looks like that is still the case.

Quite the contrary. The code you reference is what is supposed to emulate counter mode for channels 1 & 2.

The counter pins for channels 1 & 2 on the MTX are connected to the output of a divide by 13 counter, which is driven by the 4MHz CPU clock.

I have added comments below:

Code: Select all

void ctc_advance (int adv)	// adv = Number of CPU clocks since last call
    {
    static int cnt13;		// Remember left over clocks from last call
    int channel;
    cnt13 += adv;		// Add new clocks.
    for ( channel = 0; channel < N_CHANNELS; ++channel )
        {
        CHANNEL *c = &(ctc_channels[channel]);
        IF_CHAN(channel)
            if ( c->run ) diag_message(DIAG_CTC_COUNT, "CTC advance channel %d by %d clocks",
                channel, adv);
        if ( (c->control & (CC_CONSTANT|CC_RESET)) == 0 )
            {
            if ( (c->control & CC_COUNTER_MODE) == 0 )
                {
                // Timer mode code omitted
                }
            else if ( ( channel == 1 ) || ( channel == 2 ) )
                {
                int clks = cnt13 / 13;	// Number of CTC counter pulses input (CPU clocks / 13)
                int cntr = ( c->counter == 0 ) ? 0x100 : c->counter;	// Correctly interpret byte values for channel
                int cons = ( c->constant == 0 ) ? 0x100 : c->constant;
                while ( clks > 0 )
                    {
                    // Repeat while there are any CTC pulses remaining
                    if ( cntr <= clks )
                        {
                        // More pulses than CTC counter value
                        clks -= cntr;	// Deduct number of pulses for counter to reach zero
                        cntr = cons; /* Reload */	// Reset the CTC counter value
                        if ( ( c->control & CC_INTERRUPT ) && ( c->is == isNone ) )
                            {
                            // Raise interupt on that channel.
                            c->is = isPending;
                            IF_CHAN(channel)
                                diag_message(DIAG_CTC_PENDING,
                                    "CTC interrupt pending on channel %d (counter)", channel);
                            ctc_int ();
                            }
                        }
                    else
                        {
                        // Subtract the nuumber of CTC pulses remaining from the counter value
                        cntr -= clks;
                        break;	// No more pulses remaining
                        }
                    }
                c->counter = (byte) cntr;	// Store updated counter value in CTC byte register
                }
            }
        }
    cnt13 %= 13;	// Discard completed CTC pulses (multiples of 13 CPU clocks)
    }

If your code is not working, try including the switches -diag-console -diag-ctc to your MEMU command line.

[gunrock]

Quite the contrary. The code you reference is what is supposed to emulate counter mode for channels 1 & 2.

The counter pins for channels 1 & 2 on the MTX are connected to the output of a divide by 13 counter, which is driven by the 4MHz CPU clock.

See, I told you i was about to make a fool of myself! Thanks for the commented code Bill, but it was user error on my part - I never wanted counter mode in the first place- I wanted timer mode so I could access the prescaler and time constant. I think thewiz made a similar mistake elsewhere on these boards. Apologies for the noise.

This is what happens when you pick up code that you are debugging after several weeks and don't take notes beforehand.