Long time no blog. It's not that I haven't been doing anything, it's more that blogging just isn't my thing. But since I'm here... time for an update on the 6803 (MC-10 & Alice) Multi Platform Arcade Game Designer target.
First, a little background might be in order here.
What is Arcade Game Designer? It is a tool designed to make it easy to build platform games for the Sinclair Spectrum 8 bit computer. It was released 20(?) or so years ago. It consists of a game engine, a custom language used to describe how the game functions, and a development tool that simplifies game development. The tool has screen design tools, a compiler than turns the language into assembly language, etc... Once a game is built, the engine does most of the work.
Multi Platform Arcade Game Designer was designed more recently to allow developing these games on the PC, and to allow porting games written in AGD to other platforms that have the same resolution screen (256 x 192) as the Sinclair Spectrum.
I began porting the game engine more than a year ago, but distractions have prevented me from spending significant time with it until the last couple months.
The game engine is nearly complete. There are some hardware specific things like the timer interrupt that need dealt with, but I wrote example code for that long ago, so it will be easy to adapt once I change the interval for 50Hz to match the original PAL timing used by the original program. This may also get an option to use 60Hz. Since there is no joystick interface for the MC-10, that will do nothing at first. So select keyboard or it will sit there mocking you. Just kidding... I'll probably force keyboard input.
The compiler seems to be working though I have a lot of tests to do. Every call to the game engine must be checked to see if it's passing parameters correctly. The compiler even generates decent code after adding a peephole optimizer. Without the optimizer it's pretty much 8 bit code only. I gave implementing this priority over testing since the confined memory map of the MC-10. It might be difficult to fit some games into memory even with it. There is one serious issue left to be dealt with, and that is dealing with relative branches that are out of range. The 6809 version dealt with it by using a macro, and the assembler figured it out. There are two problems with this. The 6803 assembler I'm using doesn't support this, and the 6809 has long branches, which makes it easy to deal with. With the 6803, I'd have to invert the logic to branch past a jmp which is 16 bit. It's a serious problem without some additional features in the assembler.
The peephole optimizer I'm using is based on the one provided with the Z88dk package (Z88 is an early laptop by Sinclair, and dk = developer's kit). The optimizer simply performs pattern matching based on a rules file, and it isn't CPU specific. The rules file containing the patterns is going to be passed by the development tool so it can support different CPUs. Moderate changes were made to use input, output, and optimization rule filenames so that the main function can be replaced as a function call. The application can then pass the name of optimizations for other CPUs. At the moment, the optimizer is stand alone but the remaining changes needed to integrate it are trivial.
Build tests of entire games should be possible just as soon as I finish the final pieces of the engine, though some of the test scripts should be testable now by commenting out a few lines of code.
The game engine source file currently has over 10,000 lines of assembly. But that still includes much of the 6502 source code it was ported from as comments. The engine currently assembles to under 5.5K, and the final size will be close to that. The source was converted from little to big endian code for efficiency, and it made a lot of 16 bit code optimizations possible. I haven't assembled the Z80, 6502, or 6809 versions, but the 6803 code should be smaller than any of those.
Once testing is complete, and a few games are working, the code will be released on github.
Please note that the MC-10 does not fully support the 256x192 graphics mode from the factory. It requires a hardware modification to give it more internal RAM which is required for this video mode. Without the mod, the bottom 1/3 of the screen will duplicate the top 1/3 of the screen.
Here is an example of the unoptimized, and optimized compiler output. I still need to work on the comments in the optimizations, so those have been omitted, and I'm sure I will add more optimizations as I go.
Unoptimized:
...
Evnt15
ldaa #deadF ; KILL
staa <deadF
rts
Evnt16
ldaa #6
staa <charY
clr <charX
ldaa #1 ; PUT
staa <dispY
ldaa 8,x
staa <dispX
ldaa 9,x
jsr DrpOb
ldaa #1
staa <charY
ldaa #30
staa <charX
clra ; PUT
staa <dispY
ldaa 8,x
staa <dispX
ldaa 9,x
jsr DrpOb
; SOUND command
dec <numLif
rts
Evnt17
ldab #50 ; DELAY
jsr Delay
rts
Evnt18
ldab #50 ; DELAY
jsr Delay
rts
Evnt19
rts
Evnt20
rts
Optimized:
...
Evnt15
ldaa #deadF ; KILL
staa <deadF
rts
Evnt16
ldd #(6 * 256)
std <charY
ldaa #1 ; PUT
ldab 8,x
std <dispY
ldaa 9,x
jsr DrpOb
ldd #(1 * 256)+ 30
std <charY
clra ; PUT
staa <dispY
ldd 8,x
staa <dispX
tba ; move 9,x to A
jsr DrpOb
; SOUND command
dec <numLif
rts
Evnt17
ldab #50 ; DELAY
jsr Delay
rts
Evnt18
ldab #50 ; DELAY
jsr Delay
rts
Evnt19
rts
Evnt20
rts
Several optimizations have been added since this post.
