Jump to content
Asmusr

Sabre Wulf

Recommended Posts

This is a brilliant achievement , so a big well done and a big thumbs up :-)

 

trying it now on an em , but i'll try it on my ti99 this weekend. really well done and i love the menu music.

 

so whats next?

 

where were you in 1984 when we needed the arcade games that just never appeared....

 

i always knew the Ti99 was capable of so much more.

 

I pondered this with seriousness the other day. I have come to believe that a large problem back-in-the-day was not so much the talent, but rather the development tools and a dash of experience from experimentation with the hardware. In many games you can see what just might have been if; if the developers had more time, or better tools, did not have to develop in GPL, did not have to wait for hardware prototypes, etc. I am told by numerous people that my desire to develop Arkanoid on real TI hardware rather than emulation is insane considering how quickly development and testing can be done in emulation. As well, what I am doing will greatly benefit from the experience of those who pushed the hardware to limits maybe only imagined while the 4A was in production.

  • Like 1

Share this post


Link to post
Share on other sites

There's a little bit of that, but from talking to people who were coding back then too, a lot of them /wanted/ a TI but simply couldn't afford it. The talent pool was that much smaller. Add to that the difficulty in getting good documentation on the hardware, and a lot of people just went off with their Spectrums and Commodores.

 

The tools we have today make a difference, but the amount of information available also makes a huge impact. I know I wouldn't have been able to do half of the things I have without standing on the shoulders of giants before me. :)

Share this post


Link to post
Share on other sites

Very true, indeed. There was a veritable wealth of information available for the Commodore 64, in particular. Hell, the Commodore 64 Programmer's Reference Guide was $20 at a Florida Pottery store closing sale, and wound up being one of the most used books in my library. It covers everything... EVERYTHING... from nuts to doughnuts about the Commodore 64, including amazingly useful schematics.

Share this post


Link to post
Share on other sites

I would love to see a TI99 Montezumas Revenge sometime! One of my all time favorite games (along with Bump and Jump).

Seeing Rasmus his Road Hunter game, I can imagine quite a lot could be reused for Bump and Jump.

  • Like 1

Share this post


Link to post
Share on other sites

Thinking about limits of the machine from my perspective (I do not code on TI-99), on a plain TI-99 probably you can get "easily" the large part of the Colecovision games (if not all of those commercially released).

With 32K of ram you could port many msx1 games or go very close to them.

Edited by artrag

Share this post


Link to post
Share on other sites

Where were you in 1984 when we needed the arcade games that just never appeared....

 

I was in school. ;-)

 

Another problem developing cartridge games for the TI in the 1980s was that they were expected to run on an unexpanded console. If 32K RAM was required i don't think a game would have sold very well.

Share this post


Link to post
Share on other sites

I was in school. ;-)

 

Another problem developing cartridge games for the TI in the 1980s was that they were expected to run on an unexpanded console. If 32K RAM was required i don't think a game would have sold very well.

That's one of the biggest failings, I think, that TI should addressed when they came out with the v2 beige model, adding 64k. by then RAM prices had come way down, TI should had added the RAM and kept selling the thing at a reasonable price instead of (literally) giving the console away after rebate. Oh well, what should of, would of...

Edited by hloberg
  • Like 1

Share this post


Link to post
Share on other sites

That's one of the biggest failings, I think, that TI should addressed when they came out with the v2 beige model, adding 64k. by then RAM prices had come way down, TI should had added the RAM and kept selling the thing at a reasonable price instead of (literally) giving the console away after rebate. Oh well, what should of, would of...

 

Someone else will have to weigh in on this, but I think putting 64k into the console would have required a full re-do of the system as much of the address space is not fully decoded, plus because so much memory address space would have to be shared with a full 64k there would be a lot more work to do. Putting 32k in the console would have been easier (best, IMO) but might have potentially made it incompatible with third-party memory cards which cannot co-exist with the TI 32k card -- though, since so many came later it might not have been a problem.

Share this post


Link to post
Share on other sites

 

Someone else will have to weigh in on this, but I think putting 64k into the console would have required a full re-do of the system as much of the address space is not fully decoded, plus because so much memory address space would have to be shared with a full 64k there would be a lot more work to do. Putting 32k in the console would have been easier (best, IMO) but might have potentially made it incompatible with third-party memory cards which cannot co-exist with the TI 32k card -- though, since so many came later it might not have been a problem.

 

Yup, of CPU addressable 64KB—

  • 0000h – 1FFFh 8.00KB Console ROM (16-bit bus)
  • 2000h – 3FFFh 8.00KB Low memory expansion
  • 4000h – 5FFFh 8.00KB Peripheral ROMs (DSRs)
  • 6000h – 7FFFh 8.00KB Cartridge ROMs
  • 8000h – 82FFh 0.75KB Memory-mapped devices
  • 8300h – 83FFh 0.25KB Scratchpad RAM (16-bit bus)
  • 8400h – 9FFFh 7.00KB Memory-mapped devices
  • A000h – FFFFh 24.00KB High memory expansion

Total 64.00KB Total addressable by TMS9900

 

The 32KB memory expansion is not even contiguous memory!

 

...lee

Share this post


Link to post
Share on other sites

The TI is a great machine and it always was but to be honest it is a mess of a system.

 

The PEB was so very expensive and in the UK i never saw one. ever. so no one had 32k. i had to import them from the US years later.

 

Commodore really shook everything up with the c64 and 64k. Apple had release the 64k plus , Atari only had 48k as did sinclair and all these failed sooner or later. The public only saw RAM size. Bigger was better back then.

 

but back to today.

 

im deeply impressed by all this programming and the quality of the games thats coming ....brilliant work. Whats next ?

 

im so impressed. The Ti was my first computer in 1983.

 

Elite?

Commando?

mercenary

loderunner

 

 

 

 

My Ti99

32K nano PEB

various carts.

Ext basic , E/A

Edited by mjnurney

Share this post


Link to post
Share on other sites

 

Yup, of CPU addressable 64KB—

  • 0000h – 1FFFh 8.00KB Console ROM (16-bit bus)
  • 2000h – 3FFFh 8.00KB Low memory expansion
  • 4000h – 5FFFh 8.00KB Peripheral ROMs (DSRs)
  • 6000h – 7FFFh 8.00KB Cartridge ROMs
  • 8000h – 82FFh 0.75KB Memory-mapped devices
  • 8300h – 83FFh 0.25KB Scratchpad RAM (16-bit bus)
  • 8400h – 9FFFh 7.00KB Memory-mapped devices
  • A000h – FFFFh 24.00KB High memory expansion

Total 64.00KB Total addressable by TMS9900

 

The 32KB memory expansion is not even contiguous memory!

 

...lee

 

Yeah. One big thing I love about the Commodore 64 is the ability to swap out I/O and ROM space to expose the RAM "beneath." It is possible to have a full 64k available with no I/O devices or ROM. Well, 64k minus $00 and $01 which are the 6510's built-in I/O port and direction register, two bits of which handle address decoding. I take advantage of this mode for my BBS, as did much other software of the period.

 

Does the TI assume that memory at >A000 actually occupies >A000 through >FFFF? What about >2000? If one is present does it automatically require that the other is present? My thought is that if you could limit high memory to >A000 through >EFFF, you could memory-map devices into >F000 - >FFFF. Or take over >2000 space completely, etc. etc.

 

Of course the question is, why? There is already an I/O space with multiple overlaps allowed via CRU addressing. Just because, dammit.

 

Anyway, back to Sabre Wulf. :)

Share this post


Link to post
Share on other sites

That's what I meant was putting the 32k in the console, sorry. I saw somewhere where someone had put the 32k in the console and it didn't look too complected (well for an engineering type anyway). I was in school at the time the TI-99 was being sold and working at a local store that sold them. At the time I couldn't understand why TI seemed to be aiming it's console sales more at the VIC-20 (which was far inferior) then the C-64. Anyway, somewhere in an alternate reality TI did the right thing and in that universe everyone now owns a TI-99 compatible PC. ;)

Share this post


Link to post
Share on other sites

I am losing far too much time to Sabre Wulf, the game has grown on me more than it ever did all those years ago, with regards to the 32k, TI sticking all their eggs in the PEB basket probably hindered expansion for most people, a reasonably priced sidecar expansion would have been the way to go for most folk.

Share this post


Link to post
Share on other sites

Does the TI assume that memory at >A000 actually occupies >A000 through >FFFF? What about >2000? If one is present does it automatically require that the other is present? My thought is that if you could limit high memory to >A000 through >EFFF, you could memory-map devices into >F000 - >FFFF. Or take over >2000 space completely, etc. etc.

The console itself doesn't look for memory expansion, so if I understand your question correctly, technically those areas can be used however you like. However, these days I would assume that people have RAM there, rather than taking it over, since there are a good number of consoles with 32k (or more) internally. The alternate point to that is that most people who don't have RAM there have a CF7 or PEB attached, and since you'd need to use the side port to interface with those memory areas, you'd be forcing people to unplug them :)

Share this post


Link to post
Share on other sites

......TI sticking all their eggs in the PEB basket probably hindered expansion for most people, a reasonably priced sidecar expansion would have been the way to go for most folk.

You know that was what was so schizophrenic about the TI-99 line. The console was aimed at the (cheap) VIC-20 crowd while the PEB was aimed at the (expensive) Apple II crowd. Last chasing the white rabbit, back to Sabre Wolf Edited by hloberg
  • Like 1

Share this post


Link to post
Share on other sites

The address area of F000 to F0F9 and FFFA to FFFF is the 9995 CPU's on-chip RAM as used on the Geneve. The 99/8 used a castrated 9995 with no internal RAM at that location. It shadows the underlying memory contents.

Share this post


Link to post
Share on other sites

Absolute final cartridge version (unless a serious bug is discovered) with the following new features:

  • A miniature map shows your position and the screens you have visited
  • Key A views collected amulet pieces at any point in the game (also indicates which sections of the maze you need to explore)
  • A small tune at game over has been added
  • After the music has played through once, a demo mode shows screens from the game
  • Enhanced 'loading screen' graphics
  • Choosing enhanced colors on the F18A will also set max sprites per line to 32
  • Amulet will never appear in the first room
  • Changed vertical sync from VDP status polling to CRU polling

Enjoy!

SabreWulf-cart-1.3.1b.zip

  • Like 9

Share this post


Link to post
Share on other sites

Absolute final cartridge version (unless a serious bug is discovered) with the following new features:

Enjoy!

 

 

Rasmus, you forgot to mention that totally neat PDF manual included in the ZIP file! It prints up nicely!

 

 

post-35324-0-17781900-1417022600_thumb.jpg

  • Like 1

Share this post


Link to post
Share on other sites

Absolute final cartridge version (unless a serious bug is discovered) with the following new features:

  • ..
  • Changed vertical sync from VDP status polling to CRU polling

Enjoy!

 

May I ask what the reason was to switch from VDP status polling to CRU polling? Is there a particular benefit in doing so?

Share this post


Link to post
Share on other sites

 

May I ask what the reason was to switch from VDP status polling to CRU polling? Is there a particular benefit in doing so?

 

I have not been able to see any effect in Sabre Wulf, but in my screen split demo it was obvious that perhaps 1 out of 200 vertical retraces were missed on real hardware using VDP status polling. This problem disappears if you poll the CRU instead, and the number of instructions is the same.

 

Here's an example of how to wait for vsync and save the collision flag if needed.

VDPSTA    EQU   >8802

VSYNC     CLR	R12
VSYNC1    TB	2		* Test CRU bit for VDP interrupt
	  JEQ	VSYNC1	        * Loop if not set
	  MOVB	@VDPSTA,R0      * Need to clear the status register
	  ANDI R0,>2000         * Isolate collision flag
	  MOV	R0,@COINC	* Save collision flag
          B	*R11

COINC     DATA  >0000

The thing to remember is that although you will probably have CPU interrupts turned off using LIMI 0 you need to enable VDP interrupts in VDP register 1 (bit weight >20).

  • Like 1

Share this post


Link to post
Share on other sites

When I play this version on Classic99 it plays extremely fast, the sword is ineffective, and the explorer is (mostly) invincible. He can pick up objects and flowers. I do not believe earlier versions played this way on my Classic99, but I think the last time I played was v1.1-ish.

Share this post


Link to post
Share on other sites

When I play this version on Classic99 it plays extremely fast, the sword is ineffective, and the explorer is (mostly) invincible. He can pick up objects and flowers. I do not believe earlier versions played this way on my Classic99, but I think the last time I played was v1.1-ish.

 

Sounds like the vertical sync is not working. Which version of Classic99 are you using? It works fine in Q374.

Share this post


Link to post
Share on other sites

 

Sounds like the vertical sync is not working. Which version of Classic99 are you using? It works fine in Q374.

 

Ah, that was the problem: I copied an out-of-date Classic99 to the new machine. Updated to 374 and all is well!

Share this post


Link to post
Share on other sites

Absolute final cartridge version (unless a serious bug is discovered) with the following new features:

...

Enjoy!

Are there plans to sell a pre-made cartridge as with your prior games? While I can burn the PROM myself, I wouldn't mind buying a remade one if only to throw some money your way.

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