Jump to content
in8regs

Game port prospect: Acorn Electron's Gunsmoke.

Recommended Posts

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 by in8regs
  • Like 1

Share this post


Link to post
Share on other sites

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 ? :D

Share this post


Link to post
Share on other sites

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 by in8regs

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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. :cool:

Share this post


Link to post
Share on other sites

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 by sometimes99er

Share this post


Link to post
Share on other sites

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 by in8regs

Share this post


Link to post
Share on other sites
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 :D.

 

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.

Share this post


Link to post
Share on other sites

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 by in8regs

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by in8regs

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

 

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.

 

;)

Share this post


Link to post
Share on other sites

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 by in8regs
  • Like 1

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

 

 

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites
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. 🙂

 

 

 

 

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)
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 by Lee Stewart
CORRECTION per Rasmus M.
  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...