52 replies to this topic

[Rybags]

 #Quad.atr   130.02K   144 downloads

First off, thanks to Csaboover at http://www.plus4.com

This game will run in the Altirra emulator (later version the better), and on real Atari with VBXE expansion.  Be sure to enable the VBXE features within Altirra.

Note that this game is still a work-in-progress and some bugs are yet to be ironed out, and it lacks "polish"

A couple of weeks ago, I decided I'd try converting an existing C= Plus/4 game to run on the Atari.  Tried a few dozen and this one got the nod.  Of huge help was the fact the source code was available.

What is this game?  Another one of those puzzlers that'll have you pulling hair out for a while.
You control a bouncing ball, only able to move it left and right.

The objective is to clear each level of coloured blocks.  At all costs avoid the blocks containing skull & crossbones.

Also, you have to use strategy as well as skill.  You can only clear one colour of blocks at a given time.  Hitting a block with a star * will then allow you to clear blocks of that colour (your ball also changes colour to the type of blocks you can clear).

What makes it harder is that on many levels, you start with the ability to clear a certain colour, but you mustn't contact a * block until you've cleared the starting colour because there's no way to get back to that colour.

Press Fire to start the game.  SPACE pauses the game, SPACE again or Fire to resume.

If you get stuck, press Esc to restart the level at the cost of one life.

TAB allows to skip levels, but you can only skip levels that you've already completed within that gaming session, and no skipping allowed after Level 15.

Within the game menu, you can change the start level with the joystick - but once again, you can only start levels you've already reached within the current session.


And for the bugs and deficiencies...
- some text not being displayed properly.
- in Altirra, text in the right portion of the screen doesn't display in hires.  This is a problem with the emulator itself.
- when starting a level or resuming from pause, the ball will momentarily move left.  This problem crept in during conversion and will be worked on.
- sound/music not the greatest.  Music authors quite welcome.
- end of level, end of game messages displayed for not long enough.
- the colours aren't so great.  Still a work in progress.

And the story of conversion:
I got the source then went to work converting so it'd Assemble with AtAsm then run on the Plus/4.  That took all of about 30 minutes.
Next up I made the decision to do a massive rework of the code such that the game could run on an "emulated" Commodore bitmap mode by using Antic Mode 4 and DLIs changing the character set down the screen.

So many bugs crept in, that after about 6 hours over a couple of nights, I decided to scrap it and use the approach I have taken:

The original code is probably 10% modified, with another 15% or so of native Atari code tacked on.
VBXE is used to blit the Commodore bitmap onto an Atari bitmap copy, and to copy the Plus4 Attribute bytes to VBXE attribute maps.
The pain in that is that the Plus/4 pairs together the Colour nybbles for mc-bitmap pairs 01 and 10 into each byte, and same with Luma, wheras VBXE has one byte that has both Colour/Luma for each Playfield type.  So, quite a bit of code reworking to get that part done.

The sound is untouched from the original.  Since the Plus/4 only has 2 voices, we can just use 2 pairs of Pokey voices in 16-bit mode.
The program maintains "TED Shadows" and a VBlank routine simply converts the audio frequency values to what the Atari would use, and does a table lookup to generate tone or noise with the appropriate volume levels.

All up (disregarding the initial wasted hours), about 12 hours work today and 6-8 hours since last weekend to get to this stage.  The game itself was working after maybe 2-3 hours, most of the rest has been getting things looking right.

Edited by Rybags, Fri Nov 19, 2010 10:16 AM.

[flashjazzcat]

Stuck on "Select Game" screen on real (VBXE) machine. Pressing trigger just makes screen judder and repeat the menu.

[Rybags]

Strange.  Just tried the ATR on mine and it's OK (800XL + RAM320XL + VBXE running "A" Core - non RAMBO)

Note that the game itself doesn't rely on any RAM other than the system's base 48K and the VBXE RAM.

 quad10.xex   6.82K   159 downloads

That's the executable only.  But you'll likely need a games loader anyway, I doubt it'll load with most DOSes.

Should load with things like APE or the SIO2SD loader.  Most game loaders that adhere to DOS file standards should work too.

The first part of the file switches in VBXE RAM from $1000-$8FFF, so most DOSes won't like that.

Edited by Rybags, Fri Nov 19, 2010 11:01 AM.

[mimo]

Aaaaagh I want my vbxe. Over a year and still no playtime for me

[flashjazzcat]

Rybags, on Fri Nov 19, 2010 11:00 AM, said:

Strange.  Just tried the ATR on mine and it's OK (800XL + RAM320XL + VBXE running "A" Core - non RAMBO)

Note that the game itself doesn't rely on any RAM other than the system's base 48K and the VBXE RAM.

quad10.xex

That's the executable only.  But you'll likely need a games loader anyway, I doubt it'll load with most DOSes.

Should load with things like APE or the SIO2SD loader.  Most game loaders that adhere to DOS file standards should work too.

The first part of the file switches in VBXE RAM from $1000-$8FFF, so most DOSes won't like that.

Thanks - that one works fine. It looks really good, but I wasn't able to test the gameplay because the joystick trigger on port 1 is crashing the machine. That's right: when I press the trigger, the screen rolls and ultimately the screen goes black. This is nothing to do with the game; it's a system wide problem. Can't imagine what can be causing that. Any clues?

[Tezz]

looks cool, will check that out later tonight!

[Rybags]

fjc  That's a weird one.  Maybe a faulty Antic?  Could try disconnecting the LPEN pin.
I'll see about getting another build out that can work without needing the fire button.
I thought about allowing the keyboard - I suppose that'd also be a worthy addition.

Plenty of downloads but not many comments.  All the VBXE accesses should be done by Indirection but there's always that chance I missed something.

Also, I've not tested it on anything other than the default OS, so unknown how it'll go under e.g. one of the IDE centric OSes.

The game shouldn't use any RAM that you'd normally not touch - Page zero is restricted to $80-$FF.

ed - I just realised - the game doesn't work yet with D7 installs, in fact the loader just assumes anyone is running D6 install even if VBXE isn't present.
That's on the list for the next fix.

Edited by Rybags, Fri Nov 19, 2010 7:10 PM.

[pps]

Tested it with emulation (my real thing is still not build in - I NEED TIME!!! - and didn´t get the atr to load (always when you type a, the debugger starts), so the file version must be run.

The used fonts could be redone maybe, cause they´re hard to read even in the emulation. The right side is really broken, as you mentioned - but phaeron will surely repair this soon

The game itselves is fun to play. You´ve really choosen the right thing .

Hope to get it for a run on my real thing soon!

[Rybags]

The default character set is used for most of the text - the original game actually ran AND masks against the text and redefined some letters to make them look better in 160x mode.

Bummer about Altirra not yet supporting the hires/multicolour attribute flip bit.

I plan on having all the text in hires (320x), just got to do the code + blits to do the operations.

But there's also the space down the bottom - I was actually considering for a little while to just do the game in narrow DMA mode and have all the score and stuff in more traditional format.  But VBXE can do the mode switch, so I decided to do it the way we have now.

[phaeron]

Yeah, yeah, yeah....

http://www.virtualdu...-1.8-test28.zip
http://www.virtualdu...-test28-src.zip

I originally didn't implement the RES bit on attribute maps because I figured it was going to be a pain. Well, I was correct. The good news is that I also found and fixed a bug that was scrambling attribute maps when mid-screen GTIA register changes occurred. I can't guarantee that the emulation will be correct if you do something crazy like use RES=1 with GTIA mode 10 on an IR mode 5 scanline, but it should at least be better now.

The crash with the disk version only occurs if you are using the built-in ROM kernel. It's a bug in the HLE kernel, but it's occurring because the disk loader is trying to jump through the C: device init vector.

The game is simple, but it's fun. All of the bouncing in tight quarters reminds me of Arkanoid.

[flashjazzcat]

Rybags, on Fri Nov 19, 2010 6:27 PM, said:

fjc  That's a weird one.  Maybe a faulty Antic?  Could try disconnecting the LPEN pin.
I'll see about getting another build out that can work without needing the fire button.
I thought about allowing the keyboard - I suppose that'd also be a worthy addition.

Well, I took the board out of the case, disconnected a few old jumper wires, put it all back together and the fire button problem went away. Meanwhile, my KMK/IDEa stopped working stably again.

As for keyboard control: I kind of like that, although I've fished out a joystick especially to test your game.

[Rybags]

Crush one bug, two more creep out... I've had that with this over the last couple of days.

Good to see both Altirra with added compatability and fjc getting his gear (kinda) sorted.

I'll probably add keyboard tonight.  The way I'll probably implement it, rather than dicking about selecting one or the other, just have:
- SHIFT key gives same function as fire button.
- allow keys [ and ] to move the ball, conditional on no joystick input being received at that point in time.
- need an Abort Game function, probably assign SHIFT-ESC for that.


ed - looking nice on Altirra there.  Note to all that the little windows that popup in the playfield part are still multicolour, that's normal as I've not yet put in changes to zap the bits for hires there.

Edited by Rybags, Sat Nov 20, 2010 5:10 AM.

[Rybags]

 quad12.xex   7.08K   80 downloads

Small update from the last one.

Key support now added.  SHIFT performs same function as fire button (starts game, level or resumes from pause)
Left/right by , and . keys

L/R movement by keys is conditional on the joystick not being pressed in any direction.
Key movement doesn't seem to work in Altirra - I check for keys by first inquiring SKSTAT, seems it doesn't support it (?)

SHIFT-ESC will abort the game in progress, ESC alone just aborts/restarts the current level.

Level skip or selection from the menu now defaults to allowing the first 5, so you can skip some early ones when initially loading the game if you want.

Edited by Rybags, Sat Nov 20, 2010 6:12 AM.

[flashjazzcat]

Just downloaded the update: thanks. I'll give this one a spin later when I get home. IDEa is fixed (badly seated ROM), so I can see the wood for the tress now. The game is nice work; it may be apparent that I never play games (thus my skill level is very low), but it's great to see VBXE-specific software. It's quite inspirational.

[Rybags]

Youtube video recorded using Altirra.  It seems to skip the odd frame or something, the real thing is of course properly smooth. Clip edited to keep the size down.

[MaPa]

Rybags, on Fri Nov 19, 2010 6:27 PM, said:

Plenty of downloads but not many comments.

If you want a comment, here is one If it doesn't support ATARI without VBXE then it is waste of time and human resources. VBXE is surely nice piece of hardware but IMHO it does not belongs to retro computing. I can play "quadrillion" games like this just in web browser. Adding some todays hw to old ATARI is IMHO pointless. I have a PC where are thousand times better looking games (not saying better playing ). When i first saw the screenshot in first post I said to myself.. wow what a nice looking game on ATARI, but after I realized it's only for VBXE I was disappointed and lost all the interest. Don't take this post too seriously, I just think that VBXE ATARI is not an ATARI anymore.

Edited by MaPa, Sat Nov 20, 2010 7:15 AM.

[Rybags]

A normal Atari version is a possibility, but would be best done with a fresh rewrite (the game mechanics are extremely simple).

It's a "maybe" for me though.

I was thinking it could be done using the CIN mode.  64 colours by interleaved Gr. 11 lines providing colour and Gr. 15 providing the luma.  Ball could be a PM, so no loss of definition.

Maybe even use the "Simulated Mode E" trick, which could give us the score and stuff on the left of screen in hires, then switch to GTIA mode.  Switch quickly back to non-GTIA for the luma lines.

The CPU time required for the actual game movement and stuff would be pretty minimal, so there'd be no drama in losing 3/4 of it by running such a demanding kernal.

[drac030]

Rybags, could you consider setting things up so that the VBXE RAM isn't enabled in $4000-$7FFF during loading? This prevents ext from being enabled by SDX (or a loader). Also, if stuff gets loaded into VRAM, maybe it would be better to load it through an 8K window ($2000-$3FFF or $8000-$9FFF) in 8k blocks, and then enable everything the game wants after it is executed. This is surely a bit more complicated, but would also allow the game to be smoothly loaded from any DOS (incl. SDX).

Edited by drac030, Sat Nov 20, 2010 7:32 AM.

[Rybags]

Yes, I think I'll make a change like that - it probably won't work with most DOSes right now.

So much of the program had stuff "hard-coded" to where the Plus/4 bitmap lives ($2000-$3F00) that I got kinda stuck with the memory arrangements.

The blits need to have that part of RAM visible to VBXE, and Antic needs to be able to see the RAM at $6000-$8200 type of area, so I've got it setup with VBXE having a 32K page from $1000-$8FFF.

The program itself only loads at $4000-$5D00 at the moment, so I guess the solution would be to just load it to normal RAM and copy it over.

I take it SDX only does the $4000-$7FFF banking to call it's routines in a fashion transparent to the user?

ed - actually, PORTB banking should override VBXE banking in that area anyway.
I think the real problem is the fact that everything at $1000-$3FFF suddenly disappears due to the loader.

Edited by Rybags, Sat Nov 20, 2010 7:40 AM.

[drac030]

Rybags, on Sat Nov 20, 2010 7:38 AM, said:

actually, PORTB banking should override VBXE banking in that area anyway.

My FX manual says, if I understand correctly, that this depends on the way the actual ext RAM is built. And that they (ext and VRAM) should not be activated simultaneously.

[Rybags]

Not sure - my impression was that VBXE maintains a shadow of PORTB and knows to give it's banking precedence in all cases of $4000-$7FFF accesses.

In any case, I've just about got this loader fixed.  Once done, it should work with almost any DOS or games loader.

Might even try to make it so you can just press Reset and get your machine back with DOS intact and not needing any reboot.

[Rybags]

 quad12B.xex   7.18K   82 downloads

OK.  Loader should be fixed and the game should work with practically any DOS and most games loaders.

No changes to the game itself in this file, just more DOS-friendly.

Game loads into normal Atari RAM, and is then copied to VBXE RAM.

Loader lives at $6C0-$6DF and $3A00-$3BFF, game loads at $4000-$5FFF.

[electron]

Rybags: Drac030 is right, you should avoid any case when ext (PORTB) RAM is enabled simultaneously with VBXE VRAM if VBXE VRAM window is configured to appear somewhere between $4000-$7fff. In one case, when your ext RAM is standard DRAM (eg SIMM) type, VBXE RAM will take precedence. But in another case, when ext RAM is built on (for example) STATIC RAM and using CASINH or EXTSEL signals, then this ext RAM has priority over VBXE RAM. So you have 2 options:

- use different addresses for VRAM window than $4000-$7fff when PORTB ext and VRAM is enabled simulataneously, or
- always disable PORTB ext RAM prior to enabling (using) VRAM window located somewhere between $4000-$7fff

[phaeron]

Rybags, on Sat Nov 20, 2010 6:11 AM, said:

Key movement doesn't seem to work in Altirra - I check for keys by first inquiring SKSTAT, seems it doesn't support it (?)

It does, but the keyboard mode needs to be switched from cooked to raw. In the default cooked mode, the emulator auto-sends a key up as fast as possible so you can type normally; in raw mode, SKSTAT shows the keys being held down as long as they actually are.

[Syfo-Dyas]

Cool, can't wait for my VBXE to arrive in the mail.