Game port prospect: Acorn Electron's Gunsmoke.

[in8regs]

Hi! First time posting.

 

I thought of this forum/contest when I saw this on youtube:

 

Here's the BBC Micro version:

 

It looks to be well within the TI's capabilities, very simple, yet has a spark of fun to it. If there was a TI-99/4a version, I haven't run across it, anyone?

Edited March 20, 2010 by in8regs

[sometimes99er]

Much the same sound chip in BBC as TI.

 

http://en.wikipedia.org/wiki/BBC_Micro

http://en.wikipedia.org/wiki/Texas_Instruments_SN76489

 

Looks like a good choice for conversion !

[+retroclouds]

I'm not aware of a TI version of this game and it looks doable

 

Checked the mentioned wikipedia link and the BBC micro even has a TMS5220 speech synthesizer

Makes me wonder if some of the games actually used it ?

 

same sound chip + speech chip = good candidate for TI conversion ?

[in8regs]

With the Electron and BBC Micro, resolution is 160 x 256, while the TI is 256 x 192, I was wondering if the TI was able to flip the x & y, else would have to sit the TV on it's side(or add a switch to the video cable to cross x & y)/use the rotate screen option under MESS, for 1:1 graphics.

Edited March 22, 2010 by in8regs

[GroovyBee]

Just scale the graphics to the TI screen accordingly. All you really need are the game play aspects for your conversion.

 

Its a pity the TI99 isn't 6502 based. I'm working on a Beeb to Atari 7800 adaptation (using the original Beeb executable binary). I'm displaying the lower 192 scan lines of the display (and emulating the OS functionality used by the game). Its much more fun that I originally thought it would be.

[sometimes99er]

With the Electron and BBC Micro, resolution is 160 x 256, while the TI is 256 x 192, I was wondering if the TI was able to flip the x & y, else would have to sit the TV on it's side(or add a switch to the video cable to cross x & y)/use the rotate screen option under MESS, for 1:1 graphics.

Hehe, rotate under MESS. You would have to care especially for that, but I like the idea.

[sometimes99er]

Just scale the graphics to the TI screen accordingly. All you really need are the game play aspects for your conversion.

Well, I would rather generally keep the 8x8 pattern characters and rearrange the screen layout a bit.

 

Its a pity the TI99 isn't 6502 based. I'm working on a Beeb to Atari 7800 adaptation (using the original Beeb executable binary). I'm displaying the lower 192 scan lines of the display (and emulating the OS functionality used by the game). Its much more fun that I originally thought it would be.

It's hard to change old habits. Have you ever done 68000 programming ?

Edited March 22, 2010 by sometimes99er

[in8regs]

Anyone know anything about BBC Micros? The emulators, the ones I've gotten to work at least(I swear, disk/etc images never work with MESS, it's like they one offed everything,) the screen capture options and displays do 320x256 or multiples thereof, not 160x256. Did the machines double render x for 320 displayed, 160 addressed?

 

Found the answer, akin to what I thought: http://www.acornelectron.co.uk/eug/67/a-diys.html

 

gunsmoke looks to use eight colors, which according to this: http://nvg.org/bbc/history.php3 makes it mode 2, which contradicts the first link and a gunsmoke review I had run across, but whatever.

 

Here's a useful cheat to see the whole game: http://www.acornelectron.co.uk/eug/11/a-elke.html Except I have no idea where to put this. I used a bbc utility called bas2txt, after extracting the game files from the disk image with bbcexplorer 2.01, that converted two of the games files(smoke$ & smoke2$) to basic, but nothing in them matches up with the basic listed in the cheat. The two bigger game files look to be assembled or compiled code that bas2txt doesn't generate meaningful output for. MESS has it's debugger, but no disk files work with MESS.

 

BTW, the BBC has some nice ideas for utilities that the TI could benefit from: http://www.acornelectron.co.uk/eug/revs/dreamland/r-imag.html Of course, I can't find it to download it. They were doing this back in 2007, and the links have gone stale.

Edited March 22, 2010 by in8regs

[GroovyBee]

Have you ever done 68000 programming ?

 

Back in the day I used 68000 on my ST. With Devpac it was by far the fastest development solution.

 

Anyone know anything about BBC Micros? The emulators, the ones I've gotten to work at least(I swear, disk/etc images never work with MESS, it's like they one offed everything,) the screen capture options and displays do 320x256 or multiples thereof, not 160x256. Did the machines double render x for 320 displayed, 160 addressed?

 

Have you tried BeebEm?

 

http://en.wikipedia.org/wiki/BeebEm

 

Its what I've been using for my stuff. However the debugger is very basic . The emulator hasn't had any problems with any of the games I've thrown at it .

 

160x256 is mode 2 or mode 5 depending on the number of colours. There is a better description of the Beeb's video modes at the wiki for it.

 

http://en.wikipedia.org/wiki/BBC_Micro

 

For acquiring games I've been using :-

 

http://www.stairwaytohell.com

 

If you have any other Beeb problems just ask. I'm learning more about the Beeb every day.

[in8regs]

The wiki doesn't go into details.

 

160 x 256 is the logical representation of the mode while the actual display is scaled:

 

http://www.stairwaytohell.com/articles/cr-BBCMicro-CToday.html

 

"The first clever thing about the graphics is that no matter what Mode you are in, the graphics screen is made to appear 1280 pixels wide by 1024 pixels high."

 

If you were to try to match the logical, your port wouldn't look the same as the BBC output. The ratio for 1280x1024 is 1.25, which is the equivalent to 320x256.

Edited March 22, 2010 by in8regs

[GroovyBee]

160 x 256 is the logical representation of the mode while the actual display is scaled:

 

Yep! I have to divide X and Y to get the 160x256 that I need to display.

 

If you were to try to match the logical, your port wouldn't look the same as the BBC output. The ratio for 1280x1024 is 1.25, which is the equivalent of 320x256 scaled down.

 

Nope! The display looks like it does on the Beeb. You are assuming that for each video mode X and Y are scaled equally but they aren't.

[in8regs]

160 x 256 is the logical representation of the mode while the actual display is scaled:

 

Yep! I have to divide X and Y to get the 160x256 that I need to display.

 

If you were to try to match the logical, your port wouldn't look the same as the BBC output. The ratio for 1280x1024 is 1.25, which is the equivalent of 320x256 scaled down.

 

Nope! The display looks like it does on the Beeb. You are assuming that for each video mode X and Y are scaled equally but they aren't.

 

X & Y aren't scaled equally at 320x256. X is 2x the logical while Y is 1:1. If you're saying the display renders the logical resolution of 160x256, then all the BBC emulator authors have written their emulators incorrectly, as their virtual screens are 320x256. If you want to see the difference, do screen capture then scale the picture to 160x256, the result is narrower than what emulators display.

Edited March 22, 2010 by in8regs

[GroovyBee]

X & Y aren't scaled equally at 320x256. X is 2x the logical while Y is 1:1. If you're saying the display renders the logical resolution of 160x256, then all the BBC emulator authors have written their emulators incorrectly, as their virtual screens are 320x256. If you want to see the difference, do screen capture then scale the picture to 160x256, the result is narrower than what emulators display.

 

I'm not familiar with how the BBC generates its video display down to the pixel clock. However it is pretty common not to have square pixels under emulation because the aspect ratio doesn't look right.

[sometimes99er]

 

Its a pity the TI99 isn't 6502 based.

Have you ever done 68000 programming ?

Back in the day I used 68000 on my ST. With Devpac it was by far the fastest development solution.

 

Oh yes, Devpac. Anyways, personally I think 9900 is more like 68000 than 6502. The bare TI console only has 256 bytes of RAM. The 16K RAM is allocated to the VDP accessible thru a port (write address and the read of write bytes with auto increment). The Coleco and MSX uses Z80A and has 1K and 16K CPU RAM respectively.

 

[in8regs]

Attached is a cleaned up 256x192 resolution of gunsmoke. His leg and arm/gun animation and then inverse for going both directions are all that's left to do graphics, aside from the dot representing the bullet, palette flashing from getting hit, nighttime color scheme, and regular character fonts.

gunsmoke.bmp

Edited March 23, 2010 by in8regs

[+retroclouds]

very nice

[in8regs]

And the walking and aiming frames.

gunsmoke.bmp

[whoami999ster]

anyone can pick the challenge ? ... I created the project in Magellan (background and sprites) but I don't know to use with XB ... Is anybody can help me? 

GS_basic_data.xb GS_basic_pgm.xb GS_XB256_pgm.xb GS_XB_pgm.xb gunsmoke_bckg.mag gunsmoke_sprite.mag

[Asmusr]

6 hours ago, whoami999ster said:

anyone can pick the challenge ? ... I created the project in Magellan (background and sprites) but I don't know to use with XB ... Is anybody can help me

You have used ECM3 color mode and 256 characters. Unfortunately that won't work in XB without assembly support and F18A hardware.

[whoami999ster]

I suspected it  .... so what is the best I can do ? ... make a complete B&W scenario ... try to make colorized "something" ... any suggestion ?

 

Option for Magellan ? 

ECM3 = Assembly + F18A

ECM2= Assembly  

Bitmap color mode =  BASIC , XB , Assembly

Graphic 1 color mode = BASIC , XB , Assembly

[tmop69]

19 minutes ago, whoami999ster said:

I suspected it  .... so what is the best I can do ? ... make a complete B&W scenario ... try to make colorized "something" ... any suggestion ?

 

Option for Magellan ? 

ECM3 = Assembly + F18A

ECM2= Assembly  

Bitmap color mode =  BASIC , XB , Assembly

Graphic 1 color mode = BASIC , XB , Assembly

 

Use XB256 to add more characters (you can separate the Sprite and the background sets). Try to reduce/optimize the GFX to fit that specs, but it seems doable. For the code, please, do not use floating point math, so it will be easier to compile it. I can support you to have the compiled version, but no time to code the game, although it seems quite easy to implement.

 

 

[whoami999ster]

always precise and appreciate your fedback ... I guess I should start to read and learn something more on Magellan before and try with easier example or tutorial (do you know where I could find good ones?.. I found some Threads searching here in Atariage I hope I will find a sort of manual) ... 

The Game seems to be "within my reach" in XB except the "shot" ... maybe there you migh give an hand ... I know you're working at other "levels" ... 

just a clarification "floating point math" for what ? with 3 words you already confused me (LOL)

 

Thanks and Regrds

 

[tmop69]

9 minutes ago, whoami999ster said:

always precise and appreciate your fedback ... I guess I should start to read and learn something more on Magellan before and try with easier example or tutorial (do you know where I could find good ones?.. I found some Threads searching here in Atariage I hope I will find a sort of manual) ... 

The Game seems to be "within my reach" in XB except the "shot" ... maybe there you migh give an hand ... I know you're working at other "levels" ... 

just a clarification "floating point math" for what ? with 3 words you already confused me (LOL)

 

Thanks and Regrds

 

 

Just use only integers arithmetic for the math on the game. ? Moreover, integers have some limits (from -32768 to 32767). Have a look at the Compiler manual for the other limitations.

 

I suggest to just draw a basic layout of the background (windows and doors where the foes are appearing) and focus on gameplay first. In particular on how to manage the joystick for move the hero and the sight. This will speedup the debugging phase (it's really boring to have to wait for slow CHARS and HCHARS, etc to draw the screen).

 

It could be an interesting project to start increase your knowledge of XB, coding, etc. ?

 

 

 

 

[whoami999ster]

Very good hints ... thanks! 

regarding Magellan documentation any clue?

[+Lee Stewart]

13 hours ago, whoami999ster said:

Very good hints ... thanks! 

regarding Magellan documentation any clue?

 

The only documentation for Magellan is in the TXT files in the  ZIP distribution files  distribution files.

 

...lee

Edited June 2, 2021 by Lee Stewart
CORRECTION per Rasmus M.