Mucking around on the...Mega ST + ET4000

[mrbombermillzy]

In the same vein as my 'Mucking around on the C64DTV' thread, I am in turn evaluating the prospects of being able to port and run my PC based 2D game engine (or a subset of) on a variety of 8/16/32 bit machines.

The C64DTV was the first one to be prodded (viewtopic.php?f=44&t=6938) and so far looks to be a strong contender; with 2MB RAM, higher colour graphics modes, a great little blitter/DMA, digital sound and a vastly sped up (as long as coded correctly) 6510 CPU, it should easily match the 68k machines feature-wise.

My thinking behind this project umbrella is that if I can bring each viable target platform to the same level - coding similar functionality for the incrementally added graphics/sound/input routines - it may be easier to remember the (generally similar) processes and not have to re-think them again for the next platform. (Thats if I can make sure I dont have to keep re-learning/confusing each architectures' assembly language! lol)

As I have a well documented 2D graphics engine, porting the components - or subsets of - over is fairly straightforward, once the architecture specifics are understood and interfaced with.

Anyway, this time, as I have recently had the fortune of spare time to set it up, the focus is on the Atari Mega ST, with the fairly recent NOVA v1 Megabus card built by Frank Lucas.

Well, I was pipped to the post for putting out some sort of graphics demo on the Atari+ET4k combo by @fenarinarsa. However, his detailed notes have allowed me to progress quicker and I have managed to knock up this quick preliminary game engine demo over the Xmas holiday week.

P1050068.JPG

I call it Mortal Kombat remix. Id describe it as a proof of concept demo for game engine viability on the ET4000 GFX card with an ST and blitter.

P1050067.JPG

P1050066.JPG

Its a couple of characters from MK1 (one not enabled yet, but certainly included in the assets) with a background from MK3.

I have got as far as blitting a 320x240 background, overlaying a single (for now) combatant, with the relevant 3 blits - restore background/blit mask/blit character image and processing the joystick for L/R walking (U/D is for punch/kick).

And here is where we have a fork in the road with a question mark.

After adding the animation framework for the character(s) is where the issues arose.

So I am using the blitter in HOG mode and for the time being, the animation speed is fast, so I have disabled the character animation delay framework. Incidentally, the ET4000 card has an even quicker logical mask than the ST blitter, which *could* perhaps be harnessed to speed up two of the three blit processes (background restore and mask blit), but I havent quite managed to get it to work yet; there are so many unknowns with the ET4000 registers/modes, that I havent fully understood these yet.

However, the bigger problem is the less than straightforward way the ST joystick is read.

The ST joystick port needs the IKDB to be programmed to setup the joystick to be polled and this is then written via an interrupt vector to a memory location which holds the bitwise results of the joystick input.

This is fine, only the blitter in HOG mode is not allowing a big enough window for the CPU to process/service the interrupt; especially on what could end up a fairly busy game loop.

There are some options here which can solve the issue:

1. Shorten the loop to spend less time outside the joystick read.

2. Take the blitter out of HOG mode.

But being me, I always try to take advantage of the HW that is currently infront of me. And seeing that I have recently made inroads to having a H5 with a TF536 in it (oh, and I picked up a cheap Mach32 ISA card at Xmas, but thats another story!) soon on my desk, I have opted to try something else:

1. Use a printer port 2 player adapter to read the joystick (this could circumvent having to disable HOG mode, if the MFP is quicker to get the data from), but as HOG mode still...er...'HOG's the bus, I think we are heading for...

2. Use the TTRAM on the '030 card for most program data, which will allow the CPU to run in parallel with the ST bus hogging blitter AND possibly use the printer port joystick too.

But initially, Im still at the stage described further above.

So, what do you need to run the demo 'as is'?


A 4Mb Mega ST with a HDD to extract the zipped file to (file size is 166Kb zipped, ~3.2Mb uncompressed). (You will also need an ST based unzip utility).

A NOVA V1 from Frank Lucas together with an 8-bit colour (18bpp) ET4000 card with the KDA0476 DAC and the correct T0 drivers from Wolfgangs site.

An Atari compliant joystick in Port 1 (Mouse is normally in Port 0 FYI)

A screen setup that can run 320x240; any higher resolution and it will be run in the top left of the screen (Im still struggling to set a low res with this card. Hopefully Frank can guide me to getting a low res output/.bib profile, rather than a 640x480 mode set to double pixel output with virtual screen scroll).


If there is anyone out there with this exact setup, knock yourself out with the demo:

ET4K_V23.ZIP

Considering the original MK ran on a Midway T board machine with a 400x254@15bpp GFX mode, it doesnt look too bad in 256 colours @ 320x240.

But remember, I dont give any warranties or guarantees for suitability on your equipment. i.e. If this program should somehow manage to re-program your IoT kitchen appliances to kill your cat, I am not responsible, etc, etc.

Also note that there are no advanced effects at this point; no frame sync, no background (or parallax) scrolling, no background animations, character only moves L/R, punch and kicks, no opponent, unoptimised/no compression of assets etc, etc. But remember its a quickly thrown together demo. This version also doesnt have the fully animated stance animation (for the reasons described above: build is HOG mode over frame animation optimised).

Im pretty sure you cant run this on HATARI, or anything but the above, but perhaps the PiStorm in a certain ET4000 config. can do it? Who knows? I will have to get hold of one to check at some point, unless someone wants to try.

For those looking to DIY and roll their own ET4000/KDA0476 demos for the NOVA v1:

ET Screen base: $a00000
ET Register base: $bc0000

You can look at fenarinarsas demo for more details. (Other than his VME/STE base addresses, which differ, the index/register details are the same).

More progress when I get the H5/TF536 combo working...probably ;)

Also, if you want any more details just ask away.

[PhilC]

Nice work @mrbombermillzy

[mrbombermillzy]

Thanks Phil. :)

As requested, here is a version that *may* work on a 4Mb Mega STe:

MSTE_V01.ZIP

And perhaps I sould re-word the original system requirements;

As long as you have a NOVA/VOFA card Atari with the relevant screen drivers (from Ideks site), there is a fair chance that you can run this...

I just dont guarantee it. :D

[viking272]

Thanks MrB, I will hopefully get around to testing it soon.

[mrbombermillzy]

Thanks MrB, I will hopefully get around to testing it soon.

No problem.

Let me know how you get on.

[mrbombermillzy]

From the initial feedback (thanks @czietz ), it seems the demo will run successfully on the Mega STe too having modified the screen and register bases from the first version.

The only thing that I miscalculated is the actual resolution; for the time being, it will have to be run (windowed) at 1024x768x256 colours to view properly.

This is because using this fairly new card/driver setup, I dont have access to any other resolutions, so tried creating my own funky low res configuration which is apparently not compatible with everyone elses working configs. :roll:

I will see if I can figure out how to get a true 320x240 on this card and modify the demo to accomodate. (Im hoping Frank can help with this).

Oh and one more thing, make sure your first joystick move is a diagonal, or it'll glitch the screen. Sorry! Will be fixed in the next version. :D

[mrbombermillzy]

Small progress update:


I have now fixed a bug that was making the character more flickery than it should already be, which involved unnecessary constant redraw of the character, rather than redraw when the frame delay timer was counted down to zero. Because the frame delay was originally very small I didnt notice this error.

So anyway, this 'unflickers' the (now enabled) stance animation as well as the punch and kick animations, but walking left/right is still flickery as the movement is (quite correctly) not delayed by a timer like the anim frames are. (So thats on the to do list for further down the line).

Here is some stance animation prOn, as I have ramped up the frame delay, so can photograph different frames at my leisure:

P1050069.JPG

P1050070.JPG

P1050071.JPG

Can you even see those ever so slight body sway differences? Its just an excuse to show pretty pictures really! :lol:


On a more high brow note, I have solved the problem of having to use esoteric joystick solutions (like printer port adapters) to deal with the fact that the blitter is in HOG mode for the majority of the game loop time and therefore doesnt allow much joystick position polling accuracy.

I believe it was Alien from the ST Connexion demogroup who came up with programming the Hitachi 6301 keyboard controller to allow a direct pollable location, which speeds matters up considerably and allows polling the joystick position at our leisure, rather than relying on an interrupt which often may not get serviced (and therefore may have 'stagnant' joystick positional data).

So thats all running smoothly now (which also eliminates the first position glitch bug from the earlier build).

The only downside is that the setting of the ET4000AX to 320x200 still eludes me. Either from the VMG utility or by more direct methods.

I have tried setting the card to mode 13h manually; Ive even tried several VGA register unlock writes, to see if that helps, but still nothing. However, I cant seem to get much other than a 1024x768 mode on my setup, so Im not convinced its out of reach of my actual hardware combo yet. Maybe Frank Lucas or Idek can help at some point? Other than that, maybe I can hold a prize winning competition to get my card working in a native 320x200x256 at the next Cyber Legends show! :D Ive had a brief chat about it with @agranlund (thanks for the M32 code BTW) and I can see why he went down the BIOS emulation route.

I guess thats it for now.

I think the next big issue to tackle now is frame synchronisation (without any HW VBL flags or interrupts...Yikes!) so I will be rolling back all them fancy graphics and rolling up my sleeves and getting my hands very dirty in the next update, which should (hopefully) be less of an age than this last update.

Cycle counting (or more like pixel counting in my case) here I come! ;)


.