This somewhat lengthy page is intended
to give an insight into the effort that Martin puts in when
designing add-ons for the MTX, this time, it was MFX. The page evolved as Martin kept
me posted on his progress, it does not capture the detail of the
many hours that Martin explored and resolved numerous minor
issues that emerged as the design progressed. It does hopefully
give an indication of the design process and major milestones
along the way. I hope that you find it interesting - I do !
If you want to read about my turning the
prototype into a "product", see the MFX
looking for a suitable FPGA development board that might
be incorporated into a new MTX expansion card design, I did a little "Googling" and came across
this minimum system development board based on the
Altera Cyclone II FPGA.
Land Boards wiki has some details about the board.
Art of circuits website has a copy of the schematic.
Some of the FPGA's I/O are assigned to on board
components that you might need on a development board, including user LEDs,
a power LED and a push
button. In addition, some pins are connected to Vcc or
Gnd which are not required if the board uses an EP2C5
and could potentially be freed up if required.
(This information only came to light as the design
When I suggested it to Martin, it
turned out that he already had one!
This board has been
around for quite a while now and
Grant Searle had used the
board a few years ago as the basis of his
Multicomp project - creating a number of different micros
using the same FPGA development board, and Martin had
implemented it himself as shown here.
Other than a few passives and I/O
connectors, the only additional component is a RAM chip.
point, we were still thinking about a CFX replacement
and Martin did a mock up sketch of how an external MTX
add-on board might look. Note the presence of the 82C55
PPI intended to provide the CF interface.
further discussion we agreed that the CF card would be
better replaced with an SD card interface - particularly
when the majority of the required FPGA code had already
been developed by Andy for REMEMOTECH !
|Our previous MTX
expansion boards such as CFX
and MAGROM had all
been designed to be smaller than 100mm x 100mm to meet a
price point of the low cost PCB manufacturers that I had
used in the past. However, given that I really wanted to
design something that would fit inside the MTX case
(which has reduced depth at the front, restricting the
area available for mounting higher profile devices, such
as the FPGA board), we agreed that the footprint would
be larger for MFX than for our previous boards.
We also wanted to include the network interface that
Martin had previously designed (NFX)
and the desire to add an SD card slot on a daughter
board, rather than as an SMT component, all meant the
the board was going to be quite a bit larger than
those of our previous projects.
With a prospective list of
components, including :
VGA output connector
SD card interface header
CP/M Boot ROM
Decode logic for WIZ810
& MTX side RAM
Level shifting for FPGA to MTX
The board was definitely going to be
bigger than 100mm square, but if it could be kept to the
size of a
Eurocard PCB, it would fit the PCB guide slots inside the
MTX case perfectly.
a test fit of the WIZnet and FPGA development boards
mounted on a Eurocard sized piece of prototype board
and confirmed that there should be enough space to mount all
of the components inside the case. (The phono connector
above the WIZnet module is not present on a standard MTX
- it's Martin's way of accessing the MTX video output.)
It can be seen
that the mock up is the same depth as the MTX computer
board and so fits nicely in the MTX case's PCB guides.
tight, but there is adequate clearance below the
For this to work, the MFX PCB would
need to be at the same level as the MTX computer board,
i.e., the connector between the two boards would need to
be straight, like the original Memotech ones, rather
than the angled PCB connectors used for our previous
boards. Such connectors are available, but have long
lead times and are more expensive.
first version of a possible layout for the MFX board.
As usual, the layout is intended to guide Martin
during the wiring of his prototype board and is
therefore viewing the board from below, the board would
be "flipped" to mount inside the MTX, so the orange
strip at the right side would actually be located
adjacent to the internal J0 connector on the MTX
Martin's prototype uses a
Eurocard prototype board intended to have a
41612 connector at one end. Although this will not
be used by MFX, it is likely that a second MTX connector
could be mounted in this area to allow the MFX board to
be connected externally if required.
provisional layout includes for sockets for the pin
headers of the FPGA and WIZnet modules and for header
pins for the SD card and VGA connectors.
are provided for 128kB Video RAM, 128kB boot ROM and
512kB RAM chips as well as GALs for RAM and I/O decode
logic and level shifters for the connections between the
MTX (5v) and FPGA (3v).
prototype taking shape . . . .
The headers have
been mounted and the sockets for the DIP components
soldered in. Mating the board to the MTX computer board
provided further confirmation that there was enough
clearance between the components and the MTX I/O
connectors - including Martin's "special" video
side of the proto board with the memory chips and GALs
about 50% wired - another example of Martin's excellent
Martin planned to ensure that
the ROM/RAM functionality was tested and working before
moving on to the FPGA etc.
prototype, Martin chose to solder a bare SD card slot
onto a small piece of proto board, rather than use a
This view shows the sockets
for the FPGA headers and DIP packages.
The jumpers are
to allow selection of the RAM area to be provided, i.e.,
whether the RAM is being used in a MTX500 or MTX512.
the RAM and other, non-FPGA, connections fully wired,
ready to test paging of the extended RAM
fitted, ready for testing.
As you can see, the SD
card has been repositioned to allow the board to be
fitted internally and a VGA connector has been connected
to the header pins. The VGA connector has been
positioned such that it is accessible through one of the
RS232 port cut-outs. Space on the Eurocard sized board
is getting tight - the production board may need to be
the paging logic on a 64k MTX512. The MTX page port only
has 4 bits for the RAM page, so in BASIC there is the
base 64k + 14 pages of 32k from the 512k chip. With the
boot memory test needing a blank ½, page 15½ pages + 16k
common RAM is the maximum. The remaining 64k of the 512k
is unreachable. In CPM mode all of it should be visible
some initial work on converting Andy's VHDL, Martin
realised that a minor design change was needed.
The I/O code linking the FPGA to the Z80 is controlled
by the CPU clock signal which was not buffered in the
initial MFX build. As there were no free pins, an extra
buffering chip was required and rather than decoding the
I/O ports on the board, the FPGA will have to do that
for itself (and the Wiznet)
That freed up the
16V8 GAL socket for a 3rd 74LVC244 instead. There would
then be one 244 for the data bus, one for the lower half
of the address bus, and one for control signals. That
actually had some advantages, the LVC244 is cheaper than
the GAL, doesn’t need programming, and looked to have
better availability. It would also allow the inclusion
of an emulated DART if FPGA resources permit.
Martin's modified board arrangement.
hardware perspective, things were looking good - at this
stage, a quick count of the FPGA pins required was 67
out of the available 89, but the availability of the
required logic resources (Logic
Elements) needed to be confirmed.
VHDL for REMEMOTECH included emulation of the Z80 which
was obviously not required for MFX - the emulation of
the VDP was expected to be the most resource intensive
requirement and early tests has indicated that this was
not going to be an issue.
initial testing, Martin was running the board
independently of the MTX and concentrating on the video
The video output from the FPGA was
seen to be "rock steady" - a very encouraging sign,
given, the issues seen with CFX-II.
The 80 column
Test Card graphic displayed on a VGA monitor.
construction progress . . . . .
SD Card slot
connected and chips inserted
Solder/wiring side of the board
|At this point, it's
worth noting some points from a conversation between
Bill and Martin on the video side. I have recorded them
here as others may find it as interesting as I do, it
is pertinent to the MFX design and gives an
interesting insight into how the development is
progressing . . . .
developed the VDP to VGA emulation used in
Martin may run into "the same problem as [Bill] had with
the Propeller version, the difference in frame rate
between the VDP and VGA. As a result the VGA frames will
often be generated part way through a screen update. Not
much of a problem from BASIC but likely to produce
screen artifacts for games.
The ideal solution
is to double buffer the VGA output. Render VDP frames at
50Hz, synchronised with the VDP (you will need to
monitor VDPINT), but display frames at 60Hz. This means
that every sixth frame will be a duplicate, but each of
the displayed frame is clean. The Propeller had nowhere
near enough memory to do that, but if you have an FPGA
with additional RAM you may be able to do so.
Martin noted that
the development boards Cyclone II
EP2C5 has just under 5k logic
elements against 20k on the DE1's EP2C20.However the
on-board RAM definitely isn't big enough for the VDP,
meaning the VDP code will need additional tweaking to
use external memory. There's 13k RAM on the EP2C5 so my
initial thought was that was going to be 4k screen
memory, and 4k each for the alpha and graphic character
ROMs. Andy's code is actually using logic for both
character ROMs. Since the VDP won't ever fit into13k
RAM, I may recode the alpha ROM as a memory block, to
save logic resources if that means I can implement
If I get the 80 column board
working properly, then I'll add in Andy's VDP emulation
using external SRAM. I haven't looked at the code in any
detail, but like CFX-II it will only be echoing the main
VDP. VDP interrupts and the status register will still
come from the VDP so update mismatch could be a problem.
Avoiding the screen jitter that's visible on some
monitors is the aim. Andy does have some 50/60 Hz
features in the existing code, but I'm not sure they
will be of any use. While I do have a spare pin to
monitor the INT signal, monitoring VDPINT would need at
least the CTC echoing as well. As there's no direct
connection I'd have to try and watch for a interrupt
address matching the one programmed into CTC channel 0.
I'm also not sure a SRAM large enough to double/triple
buffer the display would be fast enough.
and ROM are controlled by a dedicated 22v10 GAL and are
already tested and working.
made some wiring mods to try to solve the problem of
getting data from the MTX to the FPGA.
change here is the rewiring of the data bus to allow
separate path for data in and data out, i.e., re-wired
for fully independent read and write ports on the FPGA.
VHDL updated to match the new layout and after a little
"tweaking", there is video output from the SDX boot ROM!
Despite being pretty garbled, you can make out
the text from the SDX boot screen which would normally
something like this.
|A photo of
Martin's test setup . . .
Really just an excuse
to promote the MTX to
PS/2 keyboard interface adapter that you can see
plugged into the MTX keyboard connector!
can see Martin's MTX connected to a PS/2 keyboard, which
as an added benefit in this case, allows the upper
portion of the MTX case to be completely removed for
shows the VGA output from the emulated 80 column card
when controlling it from SDX BASIC, by sending values to
the emulated ports for the display generator.
Writing to the ports as shown below allowed Martin to
display the output from the character ROM and set the
color attributes as expected.
|For the 80
column card :
Ports 48 (30h) and 49
(31h) select the memory address
(32h) selects the character in the the alpha or graphics
Port 51 (33h) controls the attribute
With the output being as expected, this
suggested that the SDX ROM display corruption could
possibly be timing
data back from the Testcard display helped identify the
Here you can see The “MFX Test card
version 1” text being read back and displayed as "IBX
Pasp car' parsiij 1". Looking at the ASCII codes
revealed that there was corruption of bits 1 and 2.
turned out to be caused by the way that the development
board dedicates some pins to allow for an external reset
signal and has pull-ups/downs on some pins that are
provided for if the board uses an EP2C8, rather than an
EP2C5 Cyclone II which is typically installed.
Reassigning the D1, D2 and D7 data bus signals made
a difference - there are a couple of issues, the green "
should be a space and the RAM data is actually from the
ROM - but this is great progress.
coming from ROM, rather than RAM, suggested that there
could be an issue with the paging logic. However, the
MTX being used for testing had a history of issues, so
Martin tried a known good MTX.
As you can see
here, the RAM test was now "OK" and the system tried to
boot and read the startup string from the SD card. There
are still issues, but progress was being made!
system at least reading the SD card, Martin concluded
that the SD access part was fine, particularly as Andy’s
SD code was unchanged and it was all synchronised to the
It appeared that it was I/O
transfers to or from the FPGA that was being corrupted
in some way. To display the boot message, it must have
read at least 2 sectors from the right place – the
boot sector and the bios sector with the text shown in
the above image.
Martin updated the wiring "schematic" with colour coding
for the "reserved" pins on the FGPA board.
reserved I/O pins reduce those available for MFX use.
Whilst not ideal, it would be possible to make these
pins available by removing the associated
pull-up/pull-down resistors on the FPGA board should it
be necessary. This would require minor modification to
every development board which is obviously not something
that we'd want to do.)
The the SRAM chip intended for
video memory wired up.
In addition, a 138
decoder has been added for the Wiznet to make it totally
independent of the FPGA for testing. One advantage of
that is that this way has already been proven to work on
With some minor optimisation of the VHDL
code, here you can see the system booted from the SD
card and running CP/M!
You can see one small
"glitch" on the screen and intermittent data errors
meant that booting sometimes failed, but things were
looking good !
difference between ReMemotech and MFX is the requirement
for level shifting between the 5v MTX and the 3v FPGA.
The external buffer for the FPGA outputs needs to be
turned on when needed and the 74HCT245 had a typical
cycle time of 20ns - the same as the 50MHz FPGA, so the
buffer could potentially have been a whole cycle behind
In an attempt to speed up the
transfer, Martin replaced the HCT part with a faster
74F245 which produced some improvement.
previously NewWord would not successfully load, this
screen shot shows NewWord has loaded and is displaying a
document when the faster buffer was used.
issue has not been completely resolved - there are a few
character errors which be seen in more detail by opening
the full size image. If the issues are down to switching
speed, then it is possible that an even faster buffer
may help, alternatively, it could be a "noise" issue.
|With the F245 parts
having apparently made some improvement, Martin decided
to try an even faster part - a 74AHCT245. These
(A=Advanced ) parts, unlike the "F" family are CMOS,
have the right output specs, and are a fraction faster
as a bonus.
In an attempt to reduce any "noise",
Martin also planned to install some resistors on the
"noise" in mind, in order to cut down the amount of
unterminated wiring on the board, Martin connected up
the Wiznet adapter. After correcting a minor wiring
error on the enable signal, the NFX programs for
FTP and HTTP were proven to be working.
Wiznet adapter connected, there appeared to be less
screen corruption and accessing the SD card appeared to
generate fewer errors. However, there were occasional
dropped connections to the Windows FTP server, possibly
supporting the belief that there were noise issues.
wiring map with minor changes, including
Correction to the Wiznet enable signal
VRAM always enabled
VRAM socket wired
for 32k/128k or 512k RAM chips
(although only 16k currently enabled)
hardware wired, Martin could then move on to looking at
the VDP, starting with the import of Andy's VHDL code.
Some changes were needed as the original assumed 20ns
dual ported RAM and that the system could read/write its
VRAM at will., whereas MFX was using 55ns single port
Having the CPU side write only was an
advantage, the host VDP would respond to reads, so
the emulated VDP didn't have to. CPU writes could be
directed to a 1 byte buffer to be transferred when the
state machine had time. (This may be how the real VDP
works without the luxury of dual port memory.) The now
redundant code to do with VDP interrupts and the status
register was also be removed.
that the extra “activity” in the FPGA also made the SD
and 80 column a little more unreliable.
faster '245s arrived and were fitted, but had no
noticeable impact on the occasional 80 column card
output glitches and the SD card reliability, but work
continued on the VDP emulation code.
real problems were diagnosed and resolved as described
later, the replacement '245 level shifters were removed
and the standard HCT versions were reinstated. The AHCT
version's extra transition speed comes with its own
problems with ringing, an unnecessary complication which
could be avoided.).
it was text mode only while Martin dealt with the
complications of single port RAM. Andy’s code takes
advantage of the speed of the local RAM to do all the
sprite processing in the horizontal blanking period.
Martin couldn't do that as not only is the SRAM a lot
slower, access also needed to be shared between the VDP
and the CPU.
Although not quite "Ready”, the
output was definitely recognisable. The obvious
corruption issues were down to missed writes (since the
real VDP deals with the reads).
some writes were being missed required some thought. In
Martin's words . . . . . . .
The FPGA clock runs as 50Mhz,
so each step of a process takes a minimum of 20ns.
That’s the master clock for the SD card and the memory.
The internal memory works in 1 cycle, the external needs
3 and I’m currently using 4 to guarantee some division
between read and write.
The VGA clock runs at 25Mhz,
so has a cycle time of 40ns. Each line is approx. 32us
made up of 800 clocks 640 active screen area 160 blank.
Andy’s code does all the sprite processing in the blank
The pixel clock for the VDP output is half
that of the VGA clock (12.5Mhz) because it’s only 256
pixels wide plus the VDP border to fill the rest. That
means - theoretically - there’s time to access the VRAM
on every pixel displayed. For text mode, only 2 reads
per character are needed. Read the character code and
then read the pixel data for the current row of that
The CPU clock is 4Mhz, 250ns cycle
time. I/O port. It’s not synchronised to the FPGA clock.
But the ROM code does honour the VDP data sheet in that
VDP writes in text mode are no closer than 8 CPU cycles
and in G2 mode 32 cycles.
It should be easy to
satisfy those timings. 8 CPU cycles is 2000ns that 25
VDP pixels. So fitting one CPU VRAM access slot for each
character position (6 or 8 pixels depending on the
mode). Should be more than enough.
screen shot was taken with the CPU having 2 slots per
character. And there are missed transfers. There must be
something else affecting the transfers other than just
the memory access slots.
It may be that solving
that helps solve the problem with the other I/O. My
biggest concern initially was the lack of
synchronisation. The start and end of the CPU I/O cycles
will never match the FPGA clock, so potentially the
could be really small part cycles at the ends as the
FPGA views things.
The other issue is the signals
pass through 3 different down shifters. Is possible they
won’t have exactly the same response times. So on a
“runt” cycle some signals might still be changing when
the FPGA starts processing the input. Noise on the bus
could produce the same result.
One of [the]
“tweaks” was to only accept an I/O request if it was
active for 2 consecutive cycles, which would hopefully
eliminate both noise, and part cycles. But alas, it
didn’t solve the problem (yet).
point, the VHDL as written, had the possibility of
writing to an I/O port more than once. This would not
have been a problem if it wrote the same data each time.
However, since the clocks aren’t synchronised, this was
likely not to be the case.
Martin stopped any
early access being part formed and causing corruption,
but also needed to put a stop any duplicate accesses and
see if that improved things further.
re-writing of the handling of the I/O ports used by the
VDP was done. Martin needed to account for the VDP worst
case 15 (of 16) VGA pixels/cycles between the CPU
issuing a write, and the VDP having the capacity to
action it. - The VDP text display was now flawless!
The re-done code stopped any IO ports being written
twice because the CPU is relatively slow compared to the
FPGA. (The 80 column board and SD card ports I/O
handling would be moved over to the same system to see
if that cured the glitches there.)
part of Graphics Mode 2 was also working.
Graphics Mode 1 was probably working to, the code ws 80%
the same a G2 mode, but not tested at this point.
Until the SD card R/W was working properly, there
was no way of testing it. Work on the sprite engine was
the next step . . . .
test screen. There was some horizontal flicker, which
appeared to be interference between the sprite engine
and the regular SRAM access sequence.
commented I need to track
down the cause as Andy’s source indicates that the
sprite stuff should only be active in the vertical
get round the sprite engine needing a total re-write for
single port RAM, I invented a work around. I have one
free SRAM access cycle per character cell per row. 384
(192 lines doubled) rows x 32 cells is more than enough
to copy a the 2k block of sprite patterns and 128 bytes
of attributes to dual port RAM. The sprite engine can
then run from the on-board DP RAM at full speed and I’ll
only need to edit a few pointers. The initial work is
promising there is something getting output. I did
manage to confirm it wasn’t the SRAM to DP RAM copy
causing those glitches.
of the sprite processing logic . . .
image is the output from the MTX VDP and the lower image
is the corresponding image being output to VGA from the
FPGA. Though not visible on the images here, there was
still a little corruption of the FPGA sprite images.
Parking that issue for the moment, Martin spent some
time investigating the corruption in reading data from
the SD card. . . .
|To get a feel of
what was going on, he used PANEL
to compare the data read from the CP/M tracks by the SDX
ROM with that read by REMEMOTECH.
through 400 bytes or so, he found 5 errors, and all 5
were bit 7 being mis-read, both high and low.
you may recall from above, in order to cater for the
board's dedicated I/O pins, the FPGA to CPU D2 and D7
connections were previously moved to the other side of
the FPGA which may have had an effect.
eliminate that as the cause, he moved the D2 and D7
connections to the same bank as the other data bits, and
having seen no improvement, Martin put his 'scope on the
data to check the signal quality.
trace is the chip select, the blue is data. The scope
was triggering on the first time SD select drops after
reset, so in theory it’s doing the low speed device
setup before moving to the 25mhz of flat out transfers.
In the upper image, with a relatively slow time base
(10ms/div), you can see that the 0v level of the select
signal is showing some pretty large spikes some
exceeding a volt. The data doesn’t look as bad until you
In the middle image, at 500us/div,
there is lots of noise apparent on the chip select line
and the data looks somewhat messy too.
third image, with an even faster time-base (50us/div),
you can see that the signal appears to have some
horrible spikes all over. With this level of noise, it
is probably unsurprising that some data corruption is
added some 100nF capacitors to the WIZnet and SD card
headers and removed the duplicate SD card header wiring.
In this trace, blue is select and yellow the data
with a time-base of 250us/div. The data is now very
clean - Martin believed that removing the wires and the
spare header probably did most of that.
|As well as
the minor hardware changes, Martin made more changes to
the VHDL that should hopefully remove any runt signals
from the FPGA if the CPU and VGA clocks happened to be
particularly badly aligned.
There was a marked
improvement. Here you can see Toado having loaded
successfully from the SD card, and . . . .
|. . .
happily running and displaying its sprites on the VGA
This is probably a milestone moment!
Martin had observed the occasional "flicker", likely
sprite related, but felt that a little code optimisation
would probably resolve it.
It seemed that as a
proof of concept, the MFX project to date had been a
success and confidence that an eventual product would
result was HIGH !
close to the final design, Martin's latest layout plan,
updated to include the extra capacitors and show the
data bit connection changes.
At this point, with
the design expected to be essentially complete, the FPGA
logic was only using around 38% of the available
resources and Martin's thoughts turned to how he might
utilise that spare capacity
enhancements were :
add multi-colour mode and
G1.5 that Andy hadn’t implemented
Andy’s math accelerator
add in some V9938/58
modes, e.g., Text 2 as used by
use the spare pins to have 2 VGA headers instead of one
use the spare pins for a simple
We discussed the pro's and con's of
the above and a few other ideas, but nothing was firmed
up at this stage.
reboot tests went well, with nice clean start-up and
some CP/M side testing done in NewWord.
other games were checked with good results, including
SMG shown here, which gave Martin some confidence that
there weren’t any major clock sync issues.
|Oddly, Andy's Turbo
managed to break the sprite emulation - the car in the
street race level failed to update, so some
investigation and further work was required which turned
out to be quite straightorward.
It seemed that
Andy used G2 mode for the race track and G1 mode for the
street race. This highlighted the fact that the G1
sprite code had not been updated when Martin re-wrote
the code to reduce the sparkles. One cut and paste and a
re-compile later and Turbo was now updating sprites
correctly in the street race.
The next step
would be to take the CFX codebase, splice in Andy’s SD
card routines instead of CF and re-write the 80 column
bits to use the “new” display.
One idea that I
had for inclusion was to have some sort of SD card
activity indication. CFX, CFX-II and REMEMOrizer all
have easily visible LEDs to indicate CF/SD "disk"
activity. With all of the components of MFX intended to
be internal, this was not going to be an option, so I
suggested that some sort of on-screen indicator should
We also discussed the media that
would be required for the SD card slot. Andy's web pages
for REMEMOTECH and REMEMOrizer both suggests that the SD
card used should be no larger than 1GB. Cards as "small"
as this are becoming less common and we had some
concerns about their long term availability (potentially
a similar issue to the lack of availability of CF
cards). To better understand the 1GB "limit", Martin did
some research around SD/SDHC differences and found that
1 gig or smaller SD cards a guaranteed to
have a block size of 1 sector, 512 bytes
SD cards report 1024 byte blocks, but should still
accept 512 bytes clock read and write commands
SDHC/SDXC cards use a different sizing system and uses
blocks between 4k and 64k
Trying to deblock a
card with 64k sectors would be very inefficient; to
update update one entry in the directory would mean
having to read and write 64k of data - SDHC support was
not going to be an option and this likely explains why
Andy stipulates cards of 1GB or less.
Andy's SD/CF file system only supports 8 x 8MB
partitions (64MB), I had envisaged that a 64/128MB would
be adequate but Martin pointed out that 512MB would be
better as it would allow Andy's
HEXTRAIN game to be loaded. This prompted Martin to
test its operation on MFX.
Martin first tried HEXTRAIN, the HTSD version from
REMEMOrizer loaded fine and the output from the VDP was
as expected. However, screen corruption was evident on
the FPGA VGA output.
This game really pushes the
MTX to the limit and relies on cramming lots of data for
the VDP into the vertical blanking period. To read the
details, see Andy's page on the technical details for
comparison, HEXTRAIN's output from the MTX VDP. The
output was perfect, confirming the data was being read
from the SD card without issue.
initial thoughts on HEXTRAIN were that it was an issue
with the shadow VDP implementation and very similar to
the problems that Andy saw when coding the
version for MTXPlus+, i.e., the problems were
possibly related to the CPU to VDP memory timings.
For HEXTRAIN, during the horizontal blank Andy
pushes pushes more data than when the VDP is drawing the
screen. Running on MFX, Martin felt that the problem was
almost certainly not the video generation itself, but
the corruption of what gets copied into the shadow VRAM
and noted that:
need my CPU to VDP memory access to work at the blanking
period rate all the time. There’s no way to synchronise
the 2 screens, even if the frame rates were the same,
and the default is they’re not!
B: The VHDL needs to be able
to cope with partial address updates. Which is one of
the tricks Andy mentioned on the MTXplus+ version write
Some rough calculations suggested
that it was not actually a timing limitation; the shadow
VDP access slots for the CPU are 0.64us apart. A Z80
can’t generate requests faster than 2us apart, and even
allowing 3 CPU cycles for the time the I/O port is
active, there’s still 1.25us inactive, that’s double the
Andy's page, HEXTRAIN and a few other games only
output the low byte of the VDP address register if the
high byte is unchanged. Implementing this feature
eliminated the gross errors in the HEXTRAIN video
There were still some minor glitches
that can be seen if you open the full size version of
also implemented an on screen disk activity indicator.
In 80 column mode, the cursor turns red when the disc is
active and for a short time after, just like a real disc
In VDP mode, the border flashed
on the VGA screen. With "standard" MTX games, such as
Rolla Bearing, there was a brief border colour change as
the game loaded, then it reverted back to the defined
border colour once loading completed.
worked well, however, when used with HEXTRAIN, which
constantly accesses the SD card when the game is
running, it was distracting. The border “flash” flips
the top bit of the border colour when the SD card has
been accessed which is why HT is showing red (colour 1
flips with colour 9).
To prevent this, a “switch”
was added that enables the VDP border flash. The switch
is set by the SDX boot ROM, and cleared by the CPM boot
implementing the "flash" feature, Martin found some
missing CPU to VDP transfer slots that were causing the
odd missed transfer.
Having corrected these,
HEXTRAIN issues now seemed to be resolved.
updated, perhaps final (?), update to the layout plan.
With plenty logic resources still available in the
FPGA, logic to decode the I/O address of the WIZnet
module was added to the FPGA. The 74HCT138 was no longer
required and could be removed.
A final word on
the (lack of) Speculator support in MFX. As noted
previously, whilst it would have been neat, it has not
been included, and is not possible for a couple of
reasons. Additional I/O decoding would be required,
which, in itself, would probably not have been too much
of a problem, but the main issue is the lack of
available I/O pins on the FPGA module. Both REMEMOTCH
and REMOMOrizer had level shifting capability on all of
the FPGA's I/O pins. With the FPGA board used in MFX,
level shifting has to be done externally and an
additional range of address lines (A9 to A15) would need
to have been made available to the FPGA to cater for
Speculator's Spectrum keyboard support. Unfortunately,
there were not enough spare I/O pins to allow this.
development, Martin's FPGA board was powered from an
external DC PSU. When we checked how Martin's system
performed when the FPGA was powered from the MTX, a
small amount of "wobble" appeared on the VDP AV output.
Martin's MTX has a PS/2
keyboard interface fitted which most users wont
have, but provision
for an external 5VDC supply was added to the PCB design.
|With the design
essentially complete and FPGA I/O allocation finalised,
it was time to take a closer look at the detail of a
suitable PCB design.
Over to Dave for that bit .
. . . details will be available
here in due course
In the meantime, Martin
continued to develop the MTX ROM software that would
interface with the FPGA.
The starting point for
the firmware used by all of our xFX expansions are Andy
SCPM and MTX
BASIC ROMs. Starting with CFX,
Martin modified the firmware to support the CFX hardware
and added a number of additional USER functions.
CFX-II added VGA output
and an 80 column option for CP/M and MTX BASIC.
Initial testing of MFX was done using Andy's REMEMOrizer
ROM to prove the concept, the next steps were to develop
custom firmware for MFX that integrated Martin's
previous firmware enhancements and introduced the
modifications required to support the MFX hardware as
well as enhancements possible with the upgraded
hardware. Some possibilities were:
Additional colours available in 80 column SDX BASIC mode
Possible introduction of some of the enhanced V9958
graphics modes developed for
of these possible enhancements were to be included with
the hardware design frozen.
shadowing the VDP's 40 column text mode, displayed on a
wide screen monitor, set to preserve the 4:3 aspect
version of the MFX specific boot ROM VDP output
Corresponding Boot ROM output to VGA
versions of the SDX boot screen were needed in CFX-II
due to the way that the Parallax Propeller VGA output
was configured. For MFX, the VGA output will default to
VDP shadow mode when booted into SDX mode, so separate
boot screens are not required and this screen never made
it into the final build. - Preserved here for posterity
of VDP output in SDX boot mode
In another change
from CFX, the "Searching for boot drive" string has been
removed. In CFX, the Compact Flash boot drive only gets
searched for on boot, in REMEMOrizer whose SD code has
been cloned for MFX , the card's presence is checked at
|There have also
been some "behind the scenes" changes based on
suggestions by Bill Brendling and Andy Key
Readable Page Port Configuration
On the MTX computer, the Page port, (Output Port 0)
is used to configure ROM and RAM; paging memory greater
than the Z80's maximum address space of 64k in and out
of the 64k range as required. As it is output only, its
current state cannot be read back by the system. BASIC
keeps a copy of the page port in the PAGE system
variable, but CP/M has no way of knowing the current
page configuration. This makes it difficult for CP/M
drivers to make use of routines in ROM. Bill suggested
that a shadow copy of the page port could be stored in
the FPGA and another I/O address configured that could
be used to read it back.
Martin had already
created a control port for the FPGA. Since the emulated
6845 CRTC for the 80 column card uses ports 38h and
39h, like the original Memotech 80 column card, Martin
thought it logical to use 3Ah for the FPGA control port.
He has now created a readable page port at the next
address, i.e., 3Bh.
The BASIC clear to end of
line ROM function prints one space character the
required number of times to clear the text to the end of
the line. This takes approximately 100 Z80 cycles per
character. For the VGA output, it is possible to offload
much of the processing for this logic to the FPGA and
tell it to execute the character print code "x" number
of times. Executing the function using the FPGA means
that that each Z80 cycle can print 1 character - a
significant increase in speed in that particular
scenario on the 80 column BASIC screen.
WIZnet Port Assignment
list of I/O ports used by Memotech and modern day
add-on devices. The NFX
prototypes used I/O ports A0 to A3 which are also used
by REMEMOrizer's arithmetic accelerator. After seeing
the NFX prototype, Andy suggested changing the I/O ports
used by NFX to unique port numbers. There are only a
very limited number of NFX prototypes in the wild, so
the impact in changing them for MFX is minor. However,
to support different port ranges, Bill has created new
versions of NFX.COM, FTPD.COM and HTTPD which have user
configurable I/O port address ranges. The port addresses
for WIZnet on MFX have now been changed to 90h to 93h.
A Minor Failure
above, one possible enhancement was the inclusion of
Andy's arithmetic accelerator into MFX. When Martin also
looked at this in detail, it turned out not to be
possible, Unfortunately, the code required over 5000
logic elements for the accelerator alone - with the FPGA
we're using only having a total of 4608 LE's, the
accelerator was obviously not going to be an option.
Enhancement - Multi colour sprites
TMS 9918 used in the MTX supports only single colour
sprites to a maximum of four on each scanline (although
a multi-colour sprite effect can be created by stacking
different colour sprites on top of each other).
single colour sprites displayed by the MTX VDP
TMS9938 introduced multi-colour sprites and Martin has
implemented this as an option for the VDP shadow display
to the VGA monitor.
The colours are set on a per
sprite basis, so even if they use the same patterns as
in the screen shot, they can have different colours. It
makes it possible to do “MFX enhanced versions” of
games, without breaking them on the normal VDP display.
Martin has buildable sources for some games and may try
customising some games in due course.
from CFX-II, Martin has
implemented an 80 column SDX BASIC text mode for
similar to that of CFX-II., but without graphics.
This is supported by the USER VGA command
USER VGA x
FPGA having some unused RAM available, I suggested to
Martin that we should code a serial number into the FPGA
Martin quickly confirmed that this was a
trivial task and implemented it, allocating 8 bytes of
read only storage, accessible via port 35h.
short from of the serial number will be presented on the
system boot screen - "MA00" in this example
displayed in the CP/M bootstrap PROM string
these screens, the serial number will display customer
initials and serial number.
Additional fields in
the serial number string will probably be used to record
the PCB hardware and firmware revision levels.
The emulated VDP has a
choice of two colour paletts using either 3 or 4 bits
per pixel colour. The "rich" palette uses 3 bits per
pixel colour and the “historical” palette, more
representative of how the MTX video output looked on a
TV back in the day, uses all 4. Selection of the palette
is done by writing to I/O port 58d (3Ah)
throw back to how the MTX VDP output looked back in the
day, Martin has implemented a vertical "hum" bar effect
in the VGA shadow mode, like you see on the MTX VDP
(You will probably need to open the full
screen image to see them.)
there were quite a few user configurable parameters for
the VGA output, Martin added a USER INFO option to the
SDX RM to provide a user friendly way to view these
In 80 column mode . . .
version of the MFX Boot Screen.
supported, the Reset <space> option to start
MAGROM has been
removed. The majority of games on MAGROM are available
as disk files, it is unlikely that (m)any users will
want to run MAGROM with MFX.
A new "Retro" mode
option has been created to invoke the vertical "hum"
bars and set the colours to the historical, less-vivid,
palette for a more authentic feel when playing games.
At this point,
the MFX firmware design was pretty much complete and our
focus moved to testing on the initial batch of PCBs that
I had manufactured.
Somewhat to my surprise,
despite the PCB design have no serious design or
manufacturing flaws, when running the firmware on the
PCB, a couple of issues came up. The problems and
resolutions are described in detail on the
MFX Engineering page. Suffice
to say, Martin was able to resolve these issues, updated
MFX PCBs have now been produced and finished products
are now being assembled.