This is the documentation for Assembly Language programmers who want to take advantage of the BIOS routines available on the MCX32-SD.
January 30, 2021
December 9, 2020
Patch for Server DIR
The first version of the BIOS code in the flash memory of the MCX32-SD contained a bug that prevents the DIR command from working correctly when accessing an Emcee server.
Any attempt to use a command like DIR 1 to display the contents of a server directory will
result in an ?IO ERROR on the MC-10 or Alice.
Click the image above to download a patch for fixing this problem.
October 31, 2020
October 9, 2020
MCX32-SD
The MCX32-SD is an expansion module for the TRS-80 MC-10 and the Matra Alice 4K/32/90. It adds 32K static RAM, 128K Flash (16 banks, 8K each) and an SD card socket. The SD card interface is managed by an Atmega328P micro controller.
The board is supported by MCX Basic version 3 which is programmed into the Flash memory. MCX Basic version 3 adds many of the language features found in Extended Color Basic on the Tandy Color Computer (CoCo) along with the I/O commands to manage file storage on the SD card or an Emcee server.
Support for PMODE 3 and 4 graphics modes has been added allowing those with an internal video RAM upgrade to take full advantage.
The SD card interface supports SD and SDHC cards formatted with either the FAT16 or FAT32 file systems. Limited support for long file names (up to 39 ASCII characters) is included.
File types recognized are:
- Basic programs as ASCII text, C10 emulator files or WAV audio.
- Machine language (binary files) as C10, WAV or CoCo Binary format.
- Basic Array files as C10 or WAV.
- Basic Data files (PRINT#, INPUT#) as ASCII text.
- PMODE graphics screens as raw data.
Assembly language programmers can utilize a set of BIOS routines to perform general-purpose random access I/O (Open, Close, Alloc, Seek, Read, Write).
Ed Snider (TheZippsterZone) has designed a 3D-printed enclosure for the board and has agreed to take on the task of manufacturing and sales of the product. Availability is expected sometime before the end of 2020.
Further details and documentation to follow as they become available.
July 1, 2020
A Logical Solution
With a new internal RAM upgrade for the MC-10 having been announced, users of the MCX128 who install this upgrade would need new logic programmed into the GAL chip if they want the added internal RAM to be available for the video display.
Without updating the logic, you can still use the MCX128 on a computer with an internal RAM upgrade but the two highest resolution graphics modes (CG6 and RG6) will remain unable to make use of the bottom third of the screen.
Previously, a special version of the GAL logic had been made available for computers with the 8K internal RAM modification. However, this logic prevented proper use of the MCX128 on an unmodified MC-10.
For those with the ability to re-program the GAL chip, a new universal version of the logic is now available that allows the MCX128 to work properly on computers with or without an internal RAM upgrade.
Download Link:
June 26, 2020
April 18, 2020
Giving an Old Mod a New Fix
Back in the September 1983 issue of Color Computer Magazine an article by Dennis Kitsz showed how to add an extra 4K of RAM to the MC-10 internally, bringing the total up to 8K.
At first it may seem a bit silly to bother with such a modification when it is far easier to add RAM via the expansion port. But because the design of the MC-10 isolated the 6847 video display generator (VDG) from the expansion port, adding RAM externally would not solve the problem wherein the two highest resolution graphics modes (each of which requires 6K of video RAM) could not be used properly. Adding RAM internally was the only way to fully support all the graphics modes.
Unfortunately the article seems to have been written prior to availability of the 16K Expansion module from Radio Shack. It is therefore unlikely that the modification was tested for compatibility with that module prior to publication. As it turns out, when an external expansion module (including the MCX128) is used in conjunction with an MC-10 that has been modified according to the instructions given in the article, there will undoubtedly be some interference seen on the video display. The intensity of the interference can vary greatly depending on what the software is doing at the time. Examples can be seen in this YouTube video by CanadianRetroThings.
After rereading Mr. Kitsz article and carefully examining the details of his modification, the cause of the interference was revealed. A 74LS139 chip was used to decode two of the address lines (A11 and A12) to produce the four individual chip-select signals for the 2K SRAMs (the two original SRAMs and the two piggybacked additions). The problem is that the Enable pin (/G) of this decoder was erroneously connected to a signal that is used by expansion modules to insert themselves into the address space. Any assertion of this signal will disable the decoder and prevent access to any of the SRAMs. If the decoder is disabled early enough within a cycle, it can overlap the period in which the VDG is trying to access RAM and thus result in the interference seen on screen.
The fix for this problem is relatively simple. Eliminate the erroneous connection of the decoder's enable pin and tie it to GND instead. This keeps the decoder enabled at all times, as it should be.
At first it may seem a bit silly to bother with such a modification when it is far easier to add RAM via the expansion port. But because the design of the MC-10 isolated the 6847 video display generator (VDG) from the expansion port, adding RAM externally would not solve the problem wherein the two highest resolution graphics modes (each of which requires 6K of video RAM) could not be used properly. Adding RAM internally was the only way to fully support all the graphics modes.
Unfortunately the article seems to have been written prior to availability of the 16K Expansion module from Radio Shack. It is therefore unlikely that the modification was tested for compatibility with that module prior to publication. As it turns out, when an external expansion module (including the MCX128) is used in conjunction with an MC-10 that has been modified according to the instructions given in the article, there will undoubtedly be some interference seen on the video display. The intensity of the interference can vary greatly depending on what the software is doing at the time. Examples can be seen in this YouTube video by CanadianRetroThings.
After rereading Mr. Kitsz article and carefully examining the details of his modification, the cause of the interference was revealed. A 74LS139 chip was used to decode two of the address lines (A11 and A12) to produce the four individual chip-select signals for the 2K SRAMs (the two original SRAMs and the two piggybacked additions). The problem is that the Enable pin (/G) of this decoder was erroneously connected to a signal that is used by expansion modules to insert themselves into the address space. Any assertion of this signal will disable the decoder and prevent access to any of the SRAMs. If the decoder is disabled early enough within a cycle, it can overlap the period in which the VDG is trying to access RAM and thus result in the interference seen on screen.
 |
| Original diagram from the article updated to show the correction. |
The fix for this problem is relatively simple. Eliminate the erroneous connection of the decoder's enable pin and tie it to GND instead. This keeps the decoder enabled at all times, as it should be.
Subscribe to:
Posts (Atom)