Titanium

[Asmusr]

It's the boot tracker code. If I don't call it, it works. It's not because the code doesn't work - it finds the right device name - but for some reason the HFDC doesn't like that this code has been called. Probably to do with enabling the ROM?

 

[/font]
[font=courier new,courier,monospace]BOOTTR MOV @>83D0,R12         * GET THE CRU BASE IN R12
      MOV @>83D2,R9          * GET THE ROM ADDRESS FOR DEVICE
      LDCR @ONES,0           * ENABLE THE ROM
      AI R9,4                * ADDING FOUR PUTS US AT THE LENGTH BYTE
      MOVB *R9+,R4           * PLACE THAT IN R4 AND INCREMENT R9
      SRL R4,8               * RIGHT JUSTIFY LENGTH IN R4
      LI R10,FILEDV          * POINT TO TEXT BUFFER
      MOVIT MOVB *R9+,*R10+  * MOV ONE BYTE FROM ROM TO TEXT BUFFER
      DEC R4                 * FINISHED?
      JNE MOVIT              * NO, DO ANOTHER BYTE
      LDCR R4,0              * DISABLE THE ROM (R4 IS ZERO AT THIS POINT)
      B *R11                 * BRANCH TO NEXT SECTION OF CODE
ONES   DATA >0101             * WORD TO TURN ON ROM IN CRU[/font]
[font=courier new,courier,monospace]

 

As I wrote earlier I copied it from "The Art Of Assembly — Part 7. Why A Duck? By Bruce Harrison 1991", and I don't fully understand how it's working. I would like to keep it, because I like to be able to run the game from any floppy drive.

[+mizapf]

ONES=0000000100000001

 

LDCR @ONES,0 means it sets to one

 

CRU@R12+0: DSR select (maps ROM into >4000)

CRU@R12+16: RAM page select at 0x5800

 

So this is a killer for HFDC, because you swap the RAM pages. Why are two bits set? Maybe try a SBO 0 here and SBZ 0 later instead of the second LDCR.

Edited August 11, 2013 by mizapf

[Asmusr]

So this is a killer for HFDC, because you swap the RAM pages. Why are two bits set? Maybe try a SBO 0 here and SBZ 0 later instead of the second LDCR.

 

Thank you, that works - try attached disk.

 

I have also renamed TITANIUM to TITA and added an XB loader.

Titanium.zip

[+retroclouds]

Very, very impressive stuff! Well done! If only Titanium could be put on a cartridge, I would buy it immediately.

This game is one more reason to finally get a cartridge PCB with some RAM on it.

 

Played the game and it is really hard. Graphics are so cool!

 

What I did notice is that I kept crashing into objects because I could not tell if they are part of the game scene or are enemies (e.g. the red bulbs)

A possible improvement would be if they somehow 'stand out' by adding a shadow.

 

I like the tune that plays on the title screen, it's very catchy. Perhaps the same tune could play during gameplay on a low volume?

 

Either way, congratulations for writing a superb arcade game!

Edited August 11, 2013 by retroclouds

[OX.]

Thanks for the update RasmusM, this reminds me of Goldrunner on the Atari ST. Would be nice with some chase and dodge bits added, ie: foes or bonuses to shoot and catch that travelled up or down the screen at a slightly faster rate than your ship thus giving a limited time to catch/shoot them, also more varied structures for the player to manouvre around to make it more challenging and interesting. Just my 2 penneth, but I think these elements contribute to a good shoot-em up.

[+retroclouds]

Just played it on the real deal and it looks so sharp on my F18A console!

 

Just another idea, perhaps you could add the beta version number on the title screen. That way you can tell the different versions apart that can / will be floating around on the internet

[Willsy]

Love the game - been playing it and admiring it! If you want to add interrupt driven speech let me know. Just let me know what phrases you would like and I can give them to you in LPC format for streaming to the speech synth. The routine to read the speech synth status needs to be in PAD RAM though. See the chapter on speech in the Editor/Assembler manual.

 

[+InsaneMultitasker]

It's the boot tracker code. If I don't call it, it works. It's not because the code doesn't work - it finds the right device name - but for some reason the HFDC doesn't like that this code has been called. Probably to do with enabling the ROM?

 

[/font]
[font=courier new,courier,monospace]BOOTTR MOV @>83D0,R12 * GET THE CRU BASE IN R12
MOV @>83D2,R9 * GET THE ROM ADDRESS FOR DEVICE
LDCR @ONES,0 * ENABLE THE ROM
AI R9,4 * ADDING FOUR PUTS US AT THE LENGTH BYTE
MOVB *R9+,R4 * PLACE THAT IN R4 AND INCREMENT R9
SRL R4,8 * RIGHT JUSTIFY LENGTH IN R4
LI R10,FILEDV * POINT TO TEXT BUFFER
MOVIT MOVB *R9+,*R10+ * MOV ONE BYTE FROM ROM TO TEXT BUFFER
DEC R4 * FINISHED?
JNE MOVIT * NO, DO ANOTHER BYTE
LDCR R4,0 * DISABLE THE ROM (R4 IS ZERO AT THIS POINT)
B *R11 * BRANCH TO NEXT SECTION OF CODE
ONES DATA >0101 * WORD TO TURN ON ROM IN CRU[/font]
[font=courier new,courier,monospace]

 

As I wrote earlier I copied it from "The Art Of Assembly — Part 7. Why A Duck? By Bruce Harrison 1991", and I don't fully understand how it's working. I would like to keep it, because I like to be able to run the game from any floppy drive.

Looks like Michael identified the culprit. And it was simple <big grin> Strange that Bruce used LDCR and loaded 16 bits when 1 bit would suffice. Then again, CRU operations are often cloaked in mystery. If you read future articles from Bruce, he complains about hardware incompatibilities and such. I wonder if his early loader was the source of some of that woe over the years.

 

As for the code, let me add a few things to my earlier comment. Essentially what Bruce is doing is picking up the last used CRU address (assumed to be the peripheral card that loaded your program) and the address of the last used device name. These pointers are set by most DSRLNK routines, including the one you are using to load your map and other data.

[color="#008800"]DJUMP2 AI R12,>0100
CLR @>83D0	
CI R12,>2000
JEQ SROM1
C R12,@CYC1
JEQ DJUMP5
MOV R12,@>83D0 [b]SAVE THE CRU ADDRESS![/b]
	 SBO >00
LI R2,>4000
CB *R2,@HEXAA
JNE DLOOP2
A @5*2+DREGS,R2
JMP DJUMP3
DLOOP3 MOV @>83D2,R2
SBO >00
DJUMP3 MOV *R2,R2
JEQ DLOOP2
MOV R2,@>83D2	 [b]SAVE POINTER TO THE DEVICE! [/b][/color]

 

Each peripheral has a linked list of the device names located in its DSR (could be ROM or RAM). Bruce makes use of these values to turn the card back on by setting R12 equal to the peripheral's CRU address (83d0) and then turning the card on with a CRU instruction. He then uses 83d2 to point to the last device via R9, skips four bytes that are part of the linked list, grabs the device name length (also in the list) and extracts the name. The final step is turning the card off, again using a CRU instruction.

 

A good representation of the DSR ROM header and linkage can be found in the "Device Service Routine Specification for the TI" Section 4.2 and 4.2.1.

Device Service Routine Specification for TI 99_4(A) Personal Computer V2.0 03-28-1983.pdf

Edited August 11, 2013 by InsaneMultitasker

[+OLD CS1]

Love the game - been playing it and admiring it! If you want to add interrupt driven speech let me know. Just let me know what phrases you would like and I can give them to you in LPC format for streaming to the speech synth. The routine to read the speech synth status needs to be in PAD RAM though. See the chapter on speech in the Editor/Assembler manual.

 

 

In your voice? That would be pretty cool.

[marc.hull]

Coming along very nice. Just got it as I've been tied up as of late and am impressed. Keep tweaking the code and you will have something really special. Congrats on your successful effort../

[+mizapf]

Apart from the CRU issues I should not forget to add my congratulations to you, Rasmus, for this outstanding programming work.

And at the same time I'm feeling somewhat sad when I see it. Because it shows me how much potential was wasted in those times.

[+mizapf]

I'm still wondering what was the intention behind the strange LDCR. I don't know of any controller that has its ROM enable at CRUBase+>10 so that one could have argued that setting both bits (CRU+0, CRU+>10) is a safe way to turn on the ROM for all cases.

 

Maybe it was just a misunderstanding about CRU programming. Or the author originally intended to load less than 8 bit into the CRU space, in which case only the first byte would have been used. That is, the code would have worked if he had written LDCR @ONES,1 (up to ,7). Still, setting more bits in CRU than required is generally a really bad idea, even when you are setting zeros.

 

I think the reason why CRU programming has always been a mystery is that at this point, you are leaving the clean, comfortable world of software and get to the rough, real world of hardware. To create useful effects you would have to study the specifications of the attached circuits.

 

The 9901 was a particular mysterious piece of hardware for me ... until I had to rewrite its emulation in MESS.

[+OLD CS1]

Apart from the CRU issues I should not forget to add my congratulations to you, Rasmus, for this outstanding programming work.

And at the same time I'm feeling somewhat sad when I see it. Because it shows me how much potential was wasted in those times.

 

I cannot tell you how often and how pissed I got seeing games on other platforms, especially ones which used the 9918A, and thinking, why no my TI?! It is great to see some awesome talent in the community.

 

AtariAge runs a store which carries a number of home-brew titles, distributed looking much like real Atari cartridges with manuals and the works. So far I am only aware of one produced home-brew cart for the TI: "Pitfall." I love playing it and would love to see more TI home-brew titles.

Edited August 11, 2013 by OLD CS1

[idflyfish]

Awesome..WTG man.

[+OLD CS1]

I am running a stock silver 4A with Speech Synth and CF7+, Extended BASIC v110. The auto-loader is fabulous, by the way. Anyway, I have found a couple of strange things. First, after the first game, some graphics on the title screen become distorted. Secondly, at random times during the game the background graphics will stop scrolling. The background scrolls as I can still shoot targets and be killed. Notice in the second picture the "GET READY" at the bottom and some shot targets out-of-place.

 

Lastly, I see the collision is a bit sensitive around some of the red dots. I can be about a tile's-width away and get destroyed.

 

(FTR, yes, that really is a CRT TV. 32". The 4A is connected by a composite-to-S-video adapter.)

[Asmusr]

Very, very impressive stuff! Well done! If only Titanium could be put on a cartridge, I would buy it immediately.

This game is one more reason to finally get a cartridge PCB with some RAM on it.

I will definitely try to make a version for the 512 K card when it's released. I'm not planning on selling it, though.

 

What I did notice is that I kept crashing into objects because I could not tell if they are part of the game scene or are enemies (e.g. the red bulbs)

A possible improvement would be if they somehow 'stand out' by adding a shadow.

I have tried to make the bulbs (I think of them as mines) stand you by making them blink, but I realize it's not that noticeable when the screen scrolls. A shadow is a great idea if it doesn't create too many new tile transitions.

 

I like the tune that plays on the title screen, it's very catchy. Perhaps the same tune could play during gameplay on a low volume?

It's using all the sound generators, so it wouldn't allow any sound effects.

 

Either way, congratulations for writing a superb arcade game!

 

Thank you!

[Asmusr]

Anyway, I have found a couple of strange things. First, after the first game, some graphics on the title screen become distorted. Secondly, at random times during the game the background graphics will stop scrolling. The background scrolls as I can still shoot targets and be killed. Notice in the second picture the "GET READY" at the bottom and some shot targets out-of-place.

 

Thank you for reporting this. I haven't seem these problems myself, but I will try to do some more testing on real hardware. It might have something to do with the XB loader which I have to admit I haven't tried on hardware.

 

Lastly, I see the collision is a bit sensitive around some of the red dots. I can be about a tile's-width away and get destroyed.

Yes, the current algorithm for collision detection with the mines is very simple - I think this can be improved in the final version.

[Asmusr]

It is great to see some awesome talent in the community.

I think there is plenty of talent but not enough time.

[Willsy]

In your voice? That would be pretty cool.

 

Yep my voice. Well, as close as the TI Speech Synth can get anyway! Apparantly, my British accent is excellent for the baddies in a game!

[sometimes99er]

FTR, yes, that really is a CRT TV. 32". The 4A is connected by a composite-to-S-video adapter.

 

And I quite like it. Like my mind does this nice time-travel retro-thing. Cool ! - And, as you might know, I'm emulation only (though it's a bit hard to stay that way all the time).

[sometimes99er]

I think there is plenty of talent but not enough time.

 

True. Even though I think of myself as talented and perhaps all over the place (brainstorming is my thing), working in teams is a pure ping-pong delight, - I still wonder if I could have done something like Parsec, back then, in the amount of time which Jim and Paul had/accumulated. But for crying out loud, it would have been fun. Damn ! - And I kind of wish there would be more initiative to do team projects. I've actually been there in a few, but for one reason or another, things fell out. Time (real life) is perhaps the most critical factor.

 

[+OLD CS1]

Yep my voice. Well, as close as the TI Speech Synth can get anyway! Apparantly, my British accent is excellent for the baddies in a game!

 

Brits are the best evil guys. Although Dawson made a great Good Guy in "Hogan's Heroes." heheheheh

 

Thank you for reporting this. I haven't seem these problems myself, but I will try to do some more testing on real hardware. It might have something to do with the XB loader which I have to admit I haven't tried on hardware.

 

Good point. Since I cannot find my E/A cartridge, I will be using the XB loader exclusively. My E/A is in its original binder which is in storage with other bindered software; I suppose I should turn up a spare or two from somewhere. I am happy to be the test for XB loader on standard hardware.

Edited August 12, 2013 by OLD CS1

[Asmusr]

I attached a new version to the first post of this thread with a few changes:

• The mines (spheres, bulbs) now have shadows, as suggested by Retroclouds. This makes them look like they are floating, and it's more apparent that they are dangerous. On level 4 where there are several hundred mines it looks a bit strange, but in general I think it's a good improvement.
  
• The collision detection with the mines is now more symmetric, but still far from pixel accurate.
  
• I have added the version number to the start screen.
  

I have not been able to replicate the problems reported by OLD CS1. The only problem I have noticed on my US console with the F18A is that the enemy ships sometimes start moving really fast in the vertical direction, but I cannot reproduce this consistently. If anyone have experienced these issues, please let me know.

 

I'm not planning anymore updates in the short term. I'm looking forward to working on other projects for a change.

[sometimes99er]

It says press fire, but it seems as if it's the spacebar instead.

[Asmusr]

It says press fire, but it seems as if it's the spacebar instead.

 

Yes, space or the joystick 1 fire button.