TEXAS INSTRUMENTS - TMS9918/9928 VDP Emulation on Propeller

digimorf · 2012-02-27 04:09

Since I'm working on this chip emulation for the project of emulating SEGA SC-3000 / SG-1000 system on Propeller, I've decided to start a specific thread on it.
This will let everybody to find out useful information on one place.

I will update this thread with the work in progress of this driver written in SPIN/ASM, with all docs/video related to this Processor, and possible use and implementation on actual propeller powered board, especially the PROP C3.

I hope you will like this Idea

digimorf · 2012-02-27 10:20

First of all here there are three videos that present the TMS9928 features, video modes, sprites and other things.
Soon I will include some videos made with this driver on my C3 during tests.

These videos were presented in a thread of http://forums.parallax.com/showthread.php?138254-TEXAS-INSTRUMENTS-TMS9918-9928-VDP-Emulation-on-Propeller forum, under Texas Ti 99/4a section.
Since also this system uses this VDP all information you can find here are all useful

Enjoy.

digimorf · 2012-02-27 14:22

These features may seems poor... Maybe you are right but maybe you are also wrong!

Remember, more than meet the eyes! ;)This chip is really flexible and uses not so much memory... This is an example of what you can do with it and some memory to store some charsets for the gameplay, and of course a lot of tricks ;)Actually this image is only a memory dump showed by the driver on my C3, not a real game but a parsed memory snapshot, right now.

You already have seen this on the other thread, but I suggest you to have a try with this game on my MSX emulator. You will see some techniques the programmers used to solve some problems, and even if not so much spirtes have been used, programmers have "played" a lot with color cycling effects, and tile animations.The use of colors in this game is really great!

http://www.digimorf.com/ASReplay_MSX - Actionscript MSX 1 emulator

Enjoy!

Ahle2 · 2012-03-02 13:44

I'm quite surprised that no one has replied to this thread. I find this very interesting and I know for a fact that these things are very
tricky to get working on the Propeller with the limited code space and processing power. This is an achievement!!
Keep up the good work digimorf.

Having optimized in pasm until my fingers bleed myself, I know that those 20 mips per cog is A LOT more than your average AVR or PIC with 20 mips.
The Propeller has got an extremely flexible instruction set and can do some things that require a lot of instruction on other MCUs with a single instruction.
Combine that with the very flexible way of handling z and c flags and conditional execution per instruction..... OOOOh, how I LOVE the Propeller!

The biggest let down is of course the missing mul and div instructions.... Because of that fact, for SOME applications a 20 mips AVR or PIC will drive circles around the Prop.

Not even multiple cogs will help for these kind of applications.

/Johannes

base2design · 2012-03-02 17:34

Ahle2 wrote: »

I'm quite surprised that no one has replied to this thread. I find this very interesting and I know for a fact that these things are very
tricky to get working on the Propeller with the limited code space and processing power. This is an achievement!!
Keep up the good work digimorf.

Having optimized in pasm until my fingers bleed myself, I know that those 20 mips per cog is A LOT more than your average AVR or PIC with 20 mips.
The Propeller has got an extremely flexible instruction set and can do some things that require a lot of instruction on other MCUs with a single instruction.
Combine that with the very flexible way of handling z and c flags and conditional execution per instruction..... OOOOh, how I LOVE the Propeller!

The biggest let down is of course the missing mul and div instructions.... Because of that fact, for SOME applications a 20 mips AVR or PIC will drive circles around the Prop. Not even multiple cogs will help for these kind of applications.

/Johannes

Good work digimorf!

Johannes, has anyone here barked for a Prop 1.5 with just mul/div... oh boy could we (well really "you") do some neat audio with that!

Oldbitcollector (Jeff) · 2012-03-02 18:47

Ahle2 wrote: »

I'm quite surprised that no one has replied to this thread. I find this very interesting and I know for a fact that these things are very
tricky to get working on the Propeller with the limited code space and processing power. This is an achievement!!
Keep up the good work digimorf.

I'm sitting here in awe of what digimorf has accomplished.. I can't wait to try out some of these myself.

OBC

potatohead · 2012-03-03 11:35

Re: No Replies.

I've been somewhat busy, but I really like this stuff! Great work so far.

Toby Seckshund · 2012-03-03 14:30

I had looked at the thread and ended looking at the programming sheets for a 9938. I always used to use the AVRs for the generic 40x25 PAL/NTSC (monochrome)but always wished for 50-80/16-25, whilst the Prop can do this I have the strange adversion of using a Prop for just one thing. This is daft, of course, as the numerous AVRs etc will end up costing more than a Prop and occupy a lot more board space ( but then I have ended up with a drawer full of them).

digimorf · 2012-07-02 10:00

Hi to everybody.
I know you are curious to see some steps ahead... so I decided to share the code I've done until now.
I would be very glad to see some evolution of this code

especially in conjunction with the ZiCog or the qZ80

The VRAM of 16K resides on the HUB memory. The eventual Z80 can have it's memory space in the Synapse o whatever SRAM expansion board. The more space in the SRAM the better because you can implement also some memory mapper used for example in MSX or SEGA MASTER SYSTEM titles.

Actually there are three video mode implememnted:
Text video
Tile Gfx I
Tile GFX II

The multi color mode is a USELESS video mode and I've never seen it used anywhere.

Sprites are rendered, but speed is a problem: If the sprite table hasn't many sprites they are rendered correctly.

You need a C3 ( but you can adapt to any Propeller board ) and a TV NTSC monitor.

The main program in this example will load a memory dump with its corresponding register configurations. And then starts the driver.
I ave included some memory dumps for each video mode. Some taken from SEGA SC-3000 games some other from MSX games. If you compile this as is, you will see a memory snapshot of the game NEMESIS II for MSX.

I know that I can optimize it much more, but I like the idea to start some nice work with you all

I am sorry that the code is not so much commented, but I think that many of you will find it useful... And we can start discuss about the techniques used.

Maybe when this will became more stable I will put it in the OBEX.

TMS9928_Emulator.zip

JT Cook · 2012-07-02 17:32

Smurf Paint-n-Play workshop on Coleco uses multicolor mode. That is what I used to test when I was writing a Coleco emulator (on the PC).

digimorf · 2012-07-02 18:03

JT Cook wrote: »

Smurf Paint-n-Play workshop on Coleco uses multicolor mode.

you are right, there are few titles. Thanks for the correction :P

In my Actionscript emulators ( MSX, SG-1000, Colecovision, Sega Master System ) I didn't used that video mode. I saw that there were a lot of games that used the gfx I and gfx II mode. So I haven't spent time in that. But sooner or later I will do it for this driver. It should be simple.

digimorf · 2012-07-04 00:58

I thought you appreciated this driver.

Anyone have tried that ? Comments ? Suggestions ?

Humanoido · 2012-07-04 01:09

This is a really great project!

Is there any goal with this emulator to include the chip's programming language?
The Propeller chip is up around 200 languages and versions that it can run.
http://humanoidolabs.blogspot.tw/2012/03/ultimate-list-of-big-brain-languages.html

My hands are full with the Propeller Elf II emulator project.
This will have a Tom Pittman Tiny Basic emulated programming language
specifically tailored for running on the Propeller chip.
http://humanoidolabs.blogspot.tw/2012/03/propeller-elf-ii.html

kuroneko · 2012-07-04 01:26

digimorf wrote: »

... Comments ?

Can you explain the intention behind this piece of code?

jump                    jmpret  back, 0-0                               ' 4                                      
                        jmp     #waitloop                               ' 4

Let's say you jump to render_mode0 (in TMS9928_RENDERER_016) but since you override the call behaviour (*_ret label & Co) with a manual jmpret the ret insn in the subroutine will return to #0 (ret defaults to jmp #0). Is that really what you want?

digimorf · 2012-07-04 01:30

thanks...

Humanoido wrote: »

This is a really great project!

Is there any goal with this emulator to include the chip's programming language?

Well This chip hasn't a particular language. It interfaces with a Microchip by a DATA bus and other lines...
Basically a processor handles commnication with it through I/O ports.

You have 8 registers to set for configuring all tables in it's 16k of VRAM, for setting up video modes, colors, sprites mode etc...
thwen you can transfer data to it's VRAM with a sequential access.

You can start with the TMS Datasheet that explains how to use it.
This chip was used in many systems such as MSX, SEGA, COLECOVISION, ARCADES... So on the WEB there are a lot of tutorials and documents about it.

You will find a lot of material

digimorf · 2012-07-04 01:49

kuroneko wrote: »
Can you explain the intention behind this piece of code?
jump                    jmpret  back, 0-0                               ' 4                                      
                        jmp     #waitloop                               ' 4                                      
Let's say you jump to render_mode0 (in TMS9928_RENDERER_016) but since you override the call behaviour (*_ret label & Co) with a manual jmpret the ret insn in the subroutine will return to #0 (ret defaults to jmp #0). Is that really what you want?

Uhm... the destinartion register for the instruction at jump label is replaced by the index of the video mode setup. so when the jmpret take place it should store the actual program location+1 into the back variable. (This instruction is like the CALL butr you can manage the destination and the back pointers separately. Right ?)
Then in the render_mode0 I have a "ret" instruction at the end, that should point the program pointer to the location number stored in the "back" variable. It shouldn't be #0...

My intention was to create an indexed jump table, driven by the videomode variable when the renderer is started by the VDP driver..
Maybe this "jump" section can be optimized or written in some other way

kuroneko · 2012-07-04 01:55

digimorf wrote: »

Uhm... the destinartion register for the instruction at jump label is replaced by the index of the video mode setup. so when the jmpret take place it should store the actual program location+1 into the back variable. (This instruction is like the CALL butr you can manage the destination and the back pointers separately. Right ?)
Then in the render_mode0 I have a "ret" instruction at the end, that should point the program pointer to the location number stored in the "back" variable. It shouldn't be #0...

Your understanding of call/ret is correct, however - as both are assembler shortcuts - ret is only effective when call is used^A. How would ret know about back? One way of resolving this could be:

jump                    jmpret  back, 0-0                               ' 4                                      

RenderTables            long    render_mode0
                        long    render_mode1
                        long    render_mode2
back                    long    waitloop

And all ret insns in the render_mode# functions should be replaced with jmp back or even jmp #waitloop (removing the need for back and jmpret, jmp would be enough).

^Acall #L is equivalent to jmpret L_ret, #L, it's an assembly time thing

digimorf · 2012-07-04 02:05

yes, thanks.. In this case the value in "back" is the same as if there was a call instruction, so my solution can be simplified with another jump method. But thanks I will try this.

kuroneko · 2012-07-04 02:15

For reference check this thread ([thread=134987]PASM Gameduino drivers[/thread]). It had a similar issue with its jump table. OK, similar would be a lie but you'll get the idea.

digimorf · 2012-07-04 02:35

thanks, I will check it out

When I will have time I will probably fix here and there and speed up a bit all the routines.
Sprite handling for example still has to be optimized to support full 32 sprites without degradation.

JT Cook · 2012-07-05 17:01

It has me curious, does it limit it to 5 sprites a scanline, or does it just draw as many as it can?

digimorf · 2012-07-05 23:40

Actually I have implemented the 5th sprite flag, but it can be bypassed of course. The problem in having more sprites in a scanline is speed and it should be solved by using some more cogs. If you want to make the advanced version of the VDP that was used in Sega Master System you should add some cog to overcome this limit. That version of the TMS9918 could manage up to 8 sprites in a line.

In this period I'm quite busy but I will post some little demo for showing how sprites are managed in the Sprite Attributes Table, and how are rendered.

cbmeeks · 2015-03-20 08:46

I know this is an old topic. Sorry for bringing it back up.

But I am very interested in seeing this project going. Have there been any updates on it?

There is an FPGA version of the 9918 (F18A) but having the 9918 run in the prop would be awesome.

As far as I'm concerned, running all 8 cogs for better emulation would be awesome. I'd like to think there is a replacement for that vintage hardware that worry about having to save a cog or two. :-)

Oh, and the sprite limit was 4 per scanline with the 5 sprite bit set if it tried to put a 5th sprite (or more) on the same scanline. But it only showed 4 (IIRC).

The F18A has the ability to show all 32 sprites on the same scanline. This would be an awesome enhancement as well.

Thanks!