TI99/4A and vector graphics

[Tursi]

7 hours ago, mizapf said:

I remember how impressed I was when I first saw Sega Outrun back in 1988, running in a racing cabinet with force feedback wheel. I was on holiday in Salou, Spain; this was somewhere near the beach.

 

Outrun is also emulated in MAME; it states:

2 x Motorola MC68000 10 MHz

Zilog Z80 4 MHz

Video: 320x224 60 Hz

 

So they spent quite a lot of computing power for this modest resolution.

Outrun also had sprite scaling in hardware and a dedicated circuit to draw the road.  There's a lot of assist in there. Drawing the road was probably the most expensive task for the 8 bit micros trying to reproduce the game... it cost almost nothing on the arcade hardware.

 

 

[HOME AUTOMATION]

Now that you mention it(dedicated hardware)... After building my first windows computer('99), and amazedly discovering that it already had digital audio capture software(sound recorder). I began trying to put it through its paces. It probably took me about a couple or so months, before I recalled my childhood ideas relating to the creation of a processor that would include and execute instructions identically to that of all other processors. Thus enabling the creation of a computer that could run games(software) just like the arcade machines! This recollection, brought about by the discovery of a screen saver, that actually let you play PAC-MAN! Than discovering that the game reproduced tricks that I believe/assume to be hardware-related. This led me to find MAME32, barely out of its infancy. Finding different MAME versions and ROMS, often incompatible... I set my sights on two games that I remembered being fantastic in their own rights ...Monaco GP, Lunar rescue. Surprisingly it seemed that I picked a red herring of sorts... I recall MAME claiming not to emulate Monaco GP, because it used no ROMS!

 

Looking it up on WIKIPEDIA today, I read Monaco GP, does use ROM, but has no processor. Sometimes I think of the steering wheel and gameplay as being somewhat analogous to playing pong sideways and in COLOR. Nothing tracks with realism, quite like dedicated analog/TTL.

[matthew180]

After posting yesterday, I fell down a slippery-slope of looking into the BattleZone Mathbox.  Apparently all the source code from many arcade (and other) games has been released, including BattleZone along with the microcode for the Mathbox: https://github.com/historicalsource/battlezone

 

Just having the original source, complete with comments, would certainly make porting the game considerably easier.  The details of the math routines used, as well as what algorithms they were based on are all documented.

 

So, with the BattleZone schematic and AM2901 datasheet, it was pretty easy to determine some interesting details about the Mathbox:

 

1. the Mathbox runs at 3MHz, i.e. 2x the 6502 clock.

2. the multiply and divide are implemented as microcode routines.

3. it provides a max of 32 functions (not all are used) and sixteen 16-bit registers (not all used).

4. the AM2902 ripple-carry chip is *not* used, which is probably the reason for the 3MHz speed.

 

The interesting bit here is the speed, i.e. 3MHz is on par with the 9900, and the microcode routines for multiply and divide really level the playing field when comparing the Mathbox to the 9900.

 

If there was a version of me that did not have a life, or too many projects already, I would like to see if a 9900-based Mathbox could be built to replace the AM2901 version, and perform as-well or better.  Although, keep in mind that the AM2901 was capable of a 8-30MHz clock, the Mathbox only runs at 3MHz.

 

I would also like to know, but could not find, pricing / cost information for the AM2901 and TMS9900 in 1979 dollars.  I'm curious which would have been the cheaper option at the time, keeping in mind that four AM2901s were needed to make a 16-bit ALU.

 

With careful use of the 9900 and scratchpad RAM on the 99/4A, and using the F18A as the vector-generator, it might be possible to do an acceptable port that is actually really close to the original.  Of course the F18A could also be used for the Mathbox, which would ease the pressure on the 9900 and require it to only be as good as the 1.5MHz 6502.

 

[whoami999ster]

Since Assembler is still to far from me I did some test in XB256 but I'm already stuck with the scrolling ...

Joe Morris recently release a great tutorial for smooth scrolling with XB256 but for a "simple background"... 

In attachment a very simple test which doesn't work and I don't understand why ... Anyone could help here ?

BZ2.xb

[1980gamer]

Try this

1175 CALL LINK("WINDOW",1,1,8,32)
1190 CALL LINK("SCRLLF",1)

May be to fast?

[apersson850]

The AM2900-series was very popular at the university I once went to. I've done my part of microcoding these chips in various lab contexts there.

[matthew180]

16 hours ago, whoami999ster said:

Since Assembler is still to far from me I did some test in XB256 but I'm already stuck with the scrolling ...

Assembly is actually pretty straightforward, it is more a matter of detail than anything.  The effort generally pays off and rewards you with a strong sense of accomplishment.  It is easier today than it ever has been to write, compile, test, and debug assembly programs, and the forum here is a huge resource of information, answers, and people very eager to help.  You should give it a try, especially if you find yourself unable to accomplish the things you want to do in other languages.

[Willsy]

3 hours ago, matthew180 said:

Assembly is actually pretty straightforward, it is more a matter of detail than anything.  The effort generally pays off and rewards you with a strong sense of accomplishment.  It is easier today than it ever has been to write, compile, test, and debug assembly programs, and the forum here is a huge resource of information, answers, and people very eager to help.  You should give it a try, especially if you find yourself unable to accomplish the things you want to do in other languages.

Especially on the TI. The 9900 instruction set is about the best I've ever used on any of the processors from the same time period: Z80, 6502, 68K etc. The 9900 assembly language is really easy.

[+mizapf]

3 hours ago, Willsy said:

Especially on the TI. The 9900 instruction set is about the best I've ever used on any of the processors from the same time period: Z80, 6502, 68K etc. The 9900 assembly language is really easy.

I recently went through the instruction set of the Z80 and concluded that I would definitely not like to write assembly programs with it. ?

 

Spoiled by a 16-bit architecture...

[+Vorticon]

14 hours ago, mizapf said:

I recently went through the instruction set of the Z80 and concluded that I would definitely not like to write assembly programs with it. ?

 

Spoiled by a 16-bit architecture...

I've written a text editor for the Coleco Adam in 8080 assembly (a subset of Z80) and I would agree that there is definitely a big paradigm shift when coming to it after cutting your teeth on the 9900, particularly the manipulation of 16bit data in the registers. That said, the Z80 instruction set is much more extensive and more flexible in my view overall than the 9900.

I did get a gentler introduction to it though by reading the book The Soul of CP/M by Mitchell Waite (https://www.pestingers.net/pdfs/other-computers/cpm-mpm/soul-of-cpm.pdf) which I cannot recommend enough if one wants to program in assembly under CP/M. From there you will have the base to tackle the larger Z80 instruction set using such references as Rodnay Zaks Programming the Z80 (https://sam.speccy.cz/asm/prog-z80_2rd-ed.pdf).

[apersson850]

I've used the Z80 very little. Actually to write some stepper motor drive programs for a PLC from Festo (the FPC 404). But I've programmed the 8080 quite a lot. It's worse than the Z80.

The best CPU I've programmed in assembly language was the Digital VAX 11/780. The Univac 1100 was rather interesting too, perhaps because it was a 36 bit machine.

Edited May 4, 2022 by apersson850

[whoami999ster]

On 5/3/2022 at 2:20 AM, 1980gamer said:

Try this

1175 CALL LINK("WINDOW",1,1,8,32)
1190 CALL LINK("SCRLLF",1)

May be to fast?

GREAT HINT!!!!! thank you soo much 

[1980gamer]

I have used this method a few times for demo stuff.

 

For the Pixel scroll, I think you may have chars defined outside to the range.  I also think they need to be consecutive chars.  65,66,67,68 = A,B,C,D

I have taken a TI development break for about a year.  I have a few projects started, actually closer to polishing phase.  I just have been crazy at work lately.

 

I did see an update for the compiler today.  Any it has a fix I needed,  but didn't think it was a bug, just how it worked.  So... I will grab that tonight!

 

[SteveB]

On 5/4/2022 at 11:13 PM, 1980gamer said:

For the Pixel scroll, I think you may have chars defined outside to the range.  I also think they need to be consecutive chars.  65,66,67,68 = A,B,C,D

I have used the pixel scrolling for the ground of Extended Parsec and this was really easy to do. You need to have the charachters in sequence, so I used a sequence of six chars (#128 to #133) and repeated them over the whole ground-line. Then a 

CALL SCPXLF(128,6,1) 

once in a while does the magic [ or CALL LINK("SCPXLF",128,6,1) if in Standard XB] .

 

But still I failed to design a larger playfield to scroll smoothly with this technique... like a cave or something. 

Edited May 7, 2022 by SteveB
My pasted code was gone ...

[+retroclouds]

On 5/4/2022 at 4:03 PM, apersson850 said:

I've used the Z80 very little. Actually to write some stepper motor drive programs for a PLC from Festo (the FPC 404). But I've programmed the 8080 quite a lot. It's worse than the Z80.

The best CPU I've programmed in assembly language was the Digital VAX 11/780. The Univac 1100 was rather interesting too, perhaps because it was a 36 bit machine.

Mind sharing how programming the Digital VAX 11/780 CPU compares to the TMS9900 CPU?

Probably would have gotten the chance at work to take a Digital VAX home, but missed-up on that opportunity as at the time I had no space whatsoever. Always liked the smooth scrolling of the VAX console/terminal though, but didn’t do any programming on that machine.

[matthew180]

5 hours ago, retroclouds said:

Mind sharing how programming the Digital VAX 11/780 CPU compares to the TMS9900 CPU?

We are getting off-topic. Apologizes to the OP.

 

The VAX is a PDP-11 with virtual memory support (VAX stands for "Virtual Address Extension"), and the PDP-11 has a very orthogonal ISA with good addressing support, eight 16-bit registers, multiply and divide instructions, etc. which makes it nice to program.  "Orthogonal" mostly means you can use most registers for the source / destination with most instructions, unlike a lot of the 8-bit (and some 16-bit) CPUs that were accumulator-based, and/or have specific registers for specific tasks, and specific instructions to use those registers, etc..

 

The PDP-11 was also the most successful minicomputer (need reference) line ever, probably due to its lower cost compared to other business/scientific computers of the day, its flexibility, and the nice to use ISA (as we know, assembly language was very dominate BITD).  The PDP-11 certainly influenced a lot of the 16 and 32 bit CPUs that came out around the same time, or a few years later; and the 9900 is no exception.  If you look at the PDP-11 instructions, you will find it very familiar:

 

https://en.wikipedia.org/wiki/PDP-11_architecture

 

I suspect the transition to/from assembly on the PDP-11 and 9900 would be pretty easy.  I have not tried personally, but I have studied the architecture quite a bit.

 

Edited May 7, 2022 by matthew180
corrections

[apersson850]

I still have the book from school about assembly programming the Digital VAX. There were some more extensions from the basic PDP-11 than just virtual addressing.

I can try to write up some comparisons in a separate thread.

[Asmusr]

On 4/29/2022 at 7:03 AM, Asmusr said:

For Battlezone, provided it's OK to require 32K and a large cartridge ROM, I think I would go for a solution like this:

• Use bitmap mode with 2/3 of the screen as playfield. Monochrome only, set all background colors to black or a static gradient.
• Draw the background mountains a few screens wide and store in ROM.
• Draw the objects at all different orientations and scales and store in ROM. For simplicity and to save space, let's restrict horizontal movement to 8 pixel boundaries.
• During the game:
  • Copy background at scroll position to a 4K linear screen buffer in 32K RAM
  • Copy objects from ROM into buffer (using OR/SOCB)
  • Copy buffer to VDP
• Execute copy routines from scratchpad using unrolled loops.
• Use sprites for explosions, crosshair, etc.

I think 10 FPS would be possible, but I haven't done the math in detail.

 

By linear screen buffer I mean a buffer where each scanline follows the next top to bottom. It's simpler to write to than a character based buffer, and it's possible to copy it to the VDP just as fast as a character based buffer, using a trick with 8 registers.

 

To speed things up, only using 1/3 of the screen could be an option.

I finally made a video as a proof of concept for my idea.

 

[Asmusr]

What's going on here is exactly as I proposed, but in addition the drawing of 3D objects to the screen buffer has been unrolled, so each instruction is either about drawing data to the buffer or moving to the next place to draw data. That takes a lot of ROM space, of course.

The rotations multiplies the ROM space by 8, and I would rather use the space for scales than rotations.

Moving stripes on the floor would do a lot for the sense of movement. I think it could be done without losing much performance. 

Edited October 14, 2022 by Asmusr

[matthew180]

Is there enough CPU time remaining to implement a decent game?

[artrag]

13 hours ago, Asmusr said:

What's going on here is exactly as I proposed, but in addition the drawing of 3D objects to the screen buffer has been unrolled, so each instruction is either about drawing data to the buffer or moving to the next place to draw data. That takes a lot of ROM space, of course.

The rotations multiplies the ROM space by 8, and I would rather use the space for scales than rotations.

Moving stripes on the floor would do a lot for the sense of movement. I think it could be done without losing much performance. 

Very impressive! The framerate is incredible!

Do you use double buffering? Writing in the lower 2/3 of the screen you can have two pages with independent PGTs.

How many byte do you need to store a precomputed frame of the objects (on average)? How do you encode the data and the offsets to jump the gaps?

Edited October 15, 2022 by artrag

[Asmusr]

10 hours ago, matthew180 said:

Is there enough CPU time remaining to implement a decent game?

That depends on how low a frame rate is allowed in a decent game. At the moment, with several big objects drawn, the frame rate is about 8 FPS. The majority of CPU time, which is constant, is spent clearing the buffer before drawing the objects and transferring it to the VDP after. That takes around 258.000 cycles (how much work can XB do in that time? 🙂), so a base frame rate around 11. A big object takes perhaps 24.000 cycles to draw, a small one perhaps 800 cycles. Maybe the drawing code could be optimized further if we had unlimited cartridge space (the demo is using 39 cartridge banks)?

 

BTW, notice how the 3D objects are clipped at the edges of the screen. There is no work involved in that, the screen buffer in RAM is simply bigger than the visible screen, and only the center part is cleared and transferred to the VDP.

[Asmusr]

2 minutes ago, artrag said:

Do you use double buffering? Writing in the lower 2/3 of the screen you can have two pages with independent PGTs

But then the colors have to be the same, right? And the top can only be used for sprites.

 

[artrag]

2 hours ago, Asmusr said:

But then the colors have to be the same, right? And the top can only be used for sprites.

 

Yes, you have to use the same color gradient in both banks but maybe placing the tiles in reverse order could work as well, blue to black and black to blue? The gradient should be on tile basis though 

[jrhodes]

16 hours ago, Asmusr said:

I finally made a video as a proof of concept for my idea.

 

I'm reminded of MS-DOS's Artic Fox. Who knew the TI was capable of stuff like this? This machine just keeps surprising me.