104 replies to this topic

[GroovyBee]

King_Salamon, on Tue Mar 16, 2010 8:31 PM, said:

GroovyBee, on Tue Mar 16, 2010 4:42 AM, said:

I've been told that Star Wars on the Beeb isn't a high resolution game so it might be possible to adapt it.

That would be awesome! But let's first tackle Tempest! lol This is quite exciting to hear though! The 7800 keeps getting better and better!

To be honest Star Wars isn't even on my conversion/adaptation list so don't get your hopes up. I've several other games I want to look at first.

[GroovyBee]

Latest version :-

 beebx.1.02.a78   128.13K   85 downloads
 beebx.1.02.bin   128K   56 downloads

No changes to the CC2 file required.

What's new :-

- Random white line bug fixed.
- Random green line bug fixed.
- Title page shows levels to play graphics.
- AVOID SPIKES appears (or not) but you still die after.
- Screen clearing optimised.

Line drawing has slowed a little due to more checking. I'm not too bothered about this at the moment because its still a first draft. As soon as the game is working correctly this issue will be addressed.

I'm slowly crawling towards fixing the end of level bug .

[Allan]

Looks great so far.

Allan

[GroovyBee]

Finally got MESS going and so here's an emulator screenshot :-



It plays too fast . With the game working in MESS and on real PAL/NTSC hardware it does look more like there is a bug in the ProSystem emulator.

[Underball]

The baddies do show up and the game runs fine in PSP7800, the Prosystem port for the Sony PSP, and in Prosystem 1.3e for Windows.

You need to update the Prosystem.dat file to include the MD5 and settings from This rom.

[4b17eb577a18a3b07a75092dc4f7e1f2]
title=Tempest
type=3
pokey=false
controller1=1
controller2=1
region=0
flags=0

That MD5 value will change every time you update the rom. make sure you update the prosystem.dat file accordingly.

You also need to enable the BIOS in Prosystem for the game to run correctly.

Edited by Underball, Wed Mar 17, 2010 2:31 PM.

[GroovyBee]

@Underball : Thanks for the information. I'm not sure why you have to make those specific changes because everything else I've done works fine.

[Underball]

GroovyBee, on Wed Mar 17, 2010 2:33 PM, said:

@Underball : Thanks for the information. I'm not sure why you have to make those specific changes because everything else I've done works fine.

Prosystem is finicky with properly recognizing 128k roms or games that need ram. That's why the .dat file is there in the first place. Standard 16k or 32k games pretty much get recognized properly, but the more complicated ones need specific instructions passed to it.

[GroovyBee]

Underball, on Wed Mar 17, 2010 2:41 PM, said:

Prosystem is finicky with properly recognizing 128k roms or games that need ram. That's why the .dat file is there in the first place. Standard 16k or 32k games pretty much get recognized properly, but the more complicated ones need specific instructions passed to it.

Its now working perfectly in ProSystem . I'll also add a new MD5 to the information given in the next release.

The video buffer is made in the external RAM so I've no idea why it only partially works . Maybe its time we overhauled the *.A78 specification?

[GroovyBee]

unhuman, on Mon Mar 15, 2010 1:04 PM, said:

April fools is only 2 weeks away....

And after the ProSystem fix has been found I say.................. April Fools? Bah humbug!!!

[Mitch]

GroovyBee, on Wed Mar 17, 2010 2:45 PM, said:

Maybe its time we overhauled the *.A78 specification?

ProSystem doesn't seem to fully parse the A78 specs but you're right that the A78 spec needs an update.

Mitch

[GroovyBee]

I've just single stepped ProSystem as it parses the *.a78 header and it detects the cart type as 3 which is the same as in the ProSystem.dat file. Looks like the problem is elsewhere.

There is an unrelated bug in cartridge size detection. The MSB of the cart size in the header is shifted left by 32 instead of 24. This wouldn't effect any carts until they reached 16MB in size which is never going to be a problem I expect.

[HammR25]

This one seems to play a lot faster which is good. I didn't really notice before but if I die the level is over and it tells me to avoid the spikes. Of course then the game ends when I can't get past the spikes.

[GroovyBee]

After a little experimentation you don't need to make changes to ProSystem.dat. All you need to do is enable the BIOS. I tested it with the first release of the game and the enemies appear.

EDIT: On further investigation its nothing to do with the BIOS or prosystem.dat. Its down to expected values in the 6502 zero page RAM. If I zero the ZP locations used by the game it doesn't work as expected on the real hardware either.

[legeek]

Awesome!

[GroovyBee]

Find attached the latest version :-

 beebx.1.03.a78   128.13K   119 downloads
 beebx.1.03.bin   128K   93 downloads

What's new in this release :-

- No need to configure ProSystem with a bios file or make changes to its database file .

The problem was due to the fact that some zero page values were being used as a seed in a random number generator. The 7800 BIOS must have been writing non-zero values to those locations.

The new code changes still don't fix the end of level death bug .

Apologies for the wild goose chase on this one. Adapting other machine's games is a new learning curve for me.

However, I still think there is a bug in ProSystem in that it really should write random values to the RAM instead of initialising it to zero before a cart image is loaded or the BIOS code executed.

[HammR25]

No need for apologies. We're not shareholders in your company.

[GroovyBee]

HammR25, on Thu Mar 18, 2010 4:51 PM, said:

No need for apologies. We're not shareholders in your company.

I know, but I don't like messing people about. New games should just load up and go.

[King_Salamon]

GroovyBee, on Thu Mar 18, 2010 5:16 PM, said:

HammR25, on Thu Mar 18, 2010 4:51 PM, said:

No need for apologies. We're not shareholders in your company.

I know, but I don't like messing people about. New games should just load up and go.

Amen to that! One of the reasons I don't use emulators... I wanna drop a cart in a system and start playing.

[GroovyBee]

Latest version :-

 beebx.1.04.a78   128.13K   168 downloads
 beebx.1.04.bin   128K   110 downloads

What's new :-

- Title page colour and text position changes.
- Level backgrounds moved down so they are all on screen.
- Score displayed bottom left.
- Level number displayed bottom right.

There are still some issues with the display :-

1) Sometimes the ship explosion is drawn going off the top of the screen when the ship is at the bottom.
2) Lives and score are briefly displayed before the screen is blanked and the level wire frame drawn. I'm probably going to have look at how the display elements are created. The Beeb has the concept of text windows and graphics windows on the same screen. I'm ignoring all that at the moment for simplicity.

The end of level death bug is still there. However I'm getting to grips with the code so its just a matter of time before that bug is tracked down.

[TrekMD]

This continues to look awesome!

[EricBall]

I'll have to plug in my 7800 & CC2 and give this a try. There's no hard limit in MARIA which would restrict you to 192 active lines - you could try and display up to 243 although overscan will probably kick in somewhere between 200 and 240. You could also try scaling the level section down by 75% so it will fit onscreen. (Or get really tricky and have a virtual screen and scroll the DLLs depending on the player's position.)

[GroovyBee]

EricBall, on Mon Mar 22, 2010 11:56 AM, said:

I'll have to plug in my 7800 & CC2 and give this a try. There's no hard limit in MARIA which would restrict you to 192 active lines - you could try and display up to 243 although overscan will probably kick in somewhere between 200 and 240. You could also try scaling the level section down by 75% so it will fit onscreen. (Or get really tricky and have a virtual screen and scroll the DLLs depending on the player's position.)

The 192 lines comes from the 16K RAM needed to store the 4BPP data for the video display's bitmap. I don't want to get into scaling because it'll slow the game down quite a bit.

In the latest version I've moved the level's wire frame graphics down the screen by adjusting the final coordinates that the 7800 has to plot. It still needs some work to get the score, high score, lives and level all on screen at the same time but I think it'll look and play fine when its been optimised.

[gambler172]

HI Mark
I checked it on real hardware;looks great
greetings Walter

[GroovyBee]

gambler172, on Mon Mar 22, 2010 1:28 PM, said:

I checked it on real hardware;looks great

Thanks for testing.

[GroovyBee]

I had a play on the Beeb versions of Star Wars and The Empire Strikes Back at the weekend on the BeebEm emulator. Both games are wire frame. Star Wars did seem a bit slow compared to how I remember the ST version playing (no surprise really given the architecture differences). I'm not sure they'd be good conversion candidates without some serious work to get them up and running at a playable speed on the 7800.