*shh* No more talking about unsupported modes, I think that kiwi73 has enough hard time already.

http://bifi.msxnet.org/msxnet/tech/tms9918a.txt

Yeah, too much useless info (at this development stage), one more bit and Kiwi73 will turn crazy...

<offtopic>

Quote:

To be clearer, it seems that some TMS-9918 support it and some don't accordingly to ther production batch.

Till now the only VDP I know that doesn't support the undocumented modes is the Toshiba T6950, a clone of the original TMS. I guess that all the real TMS support that feature.
</offtopic>

[offtopic]

Accordingly to Sean Young, also V9938 could not support this mode.
[cite]
3.5) Undocumented Mode 1 + 2

This mode is very much like Mode 1; the difference is that there can be three
different pattern tables, and control register #4 has a different meaning.

The pattern table now has 3 x 256 patterns; the screen is divided in three
parts (the top 8 character rows, the middle 8, the bottom 8). Each part can
use a different part of the pattern generator table (the first 256, the second
256, the last 256). The top part always uses the first 256 patterns in the PG.

Control register #4:
bit 7 - 3 : ignored
bit 2 : PG13; if set, PG = 2000h otherwise 0
bit 1 : if set, the last 8 rows use the 3rd pattern table otherwise 1st.
bit 0 : if set, the middle 8 rows use the 2nd pattern table otherwise 1st.

This undocumented mode is not available in the V9938 as far as I know.

[/cite]
It could be interesting to verify those info...

[/offtopic]

maybe we could continue here
http://www.msx.org/forumtopicl7073.html

Please stay on topic here - I'm having a hard enough time without the diversions

Any comments on the proposed work flows I mentioned in my post above?

kiwi73>

I've check out TommyGun last night and noticed that it doesn't actually do anything code wise. It basically manages and converts resources. This should actually make things much easier with regard to choices you can make.

With regard to the items the following would make sense:
Screens:
pretty much the same as ZX, but with two colours per 8 pixels instead of a block. In conversion you could generate a list of unique patterns and modify generate a name table accordingly. This way you could even make two smaller images and combine them with a simple offset in the name table data. Easy to handle from code.

Tiles:
Same as screens (which seems to be the case for ZX as well). Used for small objects or even single patterns.

Fonts:
Probably you should make that a single pattern editor.

Sprites:
Sprites (unlike ZX) are hardware sprites. So either 256 8x8 sprites or 64 16x16 sprites.

(not sure what UDG is for)

Map:
This is more difficult. Basically a can be built up from a number of screens and tiles that together have no more than 256 unique patterns. Probably you'd need a selector for this and a counter for how many unique patterns are used so far. For ease I would forget that you could use three different sets of 256 patterns and just make them all the same. (Maybe a challenge for later :-)
Btw, any plans to support more than 1 map?

Tiles:
Basically small name tables to the pattern set generated for this map.

Objects:
Probably the same.

Memory:
I have no idea if that is used. But if you need info on memory layout, then that should be no problem.


Resources would be Pattern tables/Color tables of a certain length and name tables of certain width/height. Because of the need for combined tables, the insert options will be slightly different, but not too hard I think.

I hope this is helpful for you. Good luck with the project!

Quote:

This is more difficult. Basically a can be built up from a number of screens and tiles that together have no more than 256 unique patterns. Probably you'd need a selector for this and a counter for how many unique patterns are used so far. For ease I would forget that you could use three different sets of 256 patterns and just make them all the same. (Maybe a challenge for later :-) Btw, any plans to support more than 1 map?

TommyGun allows to create maps only based on the tiles that you've defined before; so if the Tiles plugin only shows the available patterns bank/banks there's no mistake possible. The only one limitation is that the tiles used in a map must be from the same 256 patterns bank, you can't mix them.

The Map plugin doesn't seem specially difficult to me, could be very close to the actual...

Actually I don't plan to change the map editor much at all.
I plan to do all the name table calculations and pattern/color table optimizations in the code generator (ie. Insert Resource dialog)

I don't have any plans for multiple maps at the moment - I suppose because a map can have any number of screens - I never felt there was a need to add more maps to a game.

Sorry for the delay
I have been sick and also had a few bugs to fix for other machines.
I have started on the MSX plugins for TommyGun.
I have 7 plugins to make and 1 of them - the Screen Organiser is a pretty big addition to TommyGun so will take me a while.
I suspect I may have something to test in 2-3 weeks.
Sorry if this is a long time but I only get to program at night and of that time I only get 2 or 3 nights a week free to program TommyGun.

So if you are happy with my comments in previous posts for the goals of MSX1 support in TommyGun then I will proceed with the additions.
I supose that once you have something to play with you get a clearer idea of what I'm trying to achieve for the MSX.

Cheers

That's great news!, I'm eager to put my hands on the IDE!.