Asmusr
-
Content Count
4,000 -
Joined
-
Last visited
-
Days Won
13
Posts posted by Asmusr
-
-
1 hour ago, publicarni said:Thank you, for the new Version of Sabre.
Speed and Music are now ok, but the sprite collision is still not detected.
I tested it on my 80column System (TI99 with EVPC).
How about this?
-
2
-
-
6 hours ago, fabrice montupet said:I am encountering a problem with 'Sabre Wulf' from Rasmus. Here, the game is too fast, so fast that it is unplayable and the sprite collision is not detected. The introduction music is played very fast too.
Does this help?
-
5
-
-
11 hours ago, Airshack said:Is there a CRU base address similar to >0006 for the second joystick? How about a Test Bit series 0-4 for Joystick #2?
CRU bits 3-7 are apparently for “Joystick.” Is there some scheme here where this works for both joysticks?
Looked in EA manual and the 9901 data book, TI Tech Data, and snooped around on AtariAge.
There’s something obvious here I’m missing for sure. Maybe another bit to test for the second controller?
First you set up set column to check by writing to CRU bits 18-20 (R12=36). The column is 6 for joystick 1 and 7 for joystick 2.
Then you read the values from CRU bits 3-7 (R12=6).
See www.unige.ch/medecine/nouspikel/ti99/keyboard.htm#quick%20scan
Edited: some numbers were hex values.
-
1
-
-
2 hours ago, globeron said:Thank you! So the reason 9929 does not work in a PAL European version of the TI is the frequency 60Hz ?
No, it *should* work. A PAL EU TI-99/4A needs a 9929A (50 Hz) and a NTSC US TI-99/4A needs a 9918A (60 Hz). The 9928A is not used.
-
41 minutes ago, mizapf said:Interesting! Would you mind sharing this test program as well?
Here you are.
-
1
-
-
And this is how it looks when the sprite duplication issue is not emulated:
I'm just warning new developers: the half-bitmap mode may be tempting to use but your plans may be shattered when you discover you can only use sprites 0-7.
-
6
-
-
9 hours ago, GDMike said:A video explaining what is going on would be cool.
Several topics have been discussed today, but this is a video of the sprite duplication in half bitmap mode with 2K patterns and color tables. The top 3rd contains sprites 1-4 (not duplicated) and sprites 17-20 (duplicated). The Sprite I move around is number 8. If it's located in the 1st part, it is duplicated to the 2nd and the 3rd parts. If it's located in the 2nd part it is not duplicated. If it's located in the 3rd part it is hidden.
This is how it looks in JS99er:
-
2
-
-
That was fast 🙂. I will try to copy what you did.
-
3
-
-
44 minutes ago, Tursi said:They all seem to be doing the right thing - did I test the wrong thing?
1 hour ago, mizapf said:So why this is wrong?
Sorry, it looks like only the cartridge image, which is what I used on my real hardware (and in Classic99/JS99er), is returning DIV=0000, so there must be something wrong with it.
-
1
-
-
I finally set up an NTSC machine again and was able to view the demo in its full glory, and it looks amazing - much better than on emulation. I wonder if there would be time enough during vertical blank to play some music?
-
2
-
-
-
1 hour ago, Willsy said:>8300
My tests show that the answer on hardware (and MAME) is >8302. Classic99 says >8300. And JS99er also says >8300 because the CPU emulation is ported from Classic99. @Tursi
I have attached the test code from the user, which is using different values. The relevant output is the second line where R4=A082 on hardware and A080 in Classic99/JS99er.
Edit: The output on line 5 is about overflowing workspace by dividing R15. In that case Classic99 appears to be right and MAME is wrong (at least the old version I'm using). It should read DIV=0000 and not DIV=0100.
-
2
-
-
What would you expect the value of R1 to be after running this code?
LWPI >8300 STWP R0 MOV *R0+,R1I would have expected >8300, but according to a bug report for js99er the correct value is >8302.
-
38 minutes ago, Jeff White said:For my application, I needed to have 768 dynamically generated unique tiles on the screen, but only a foreground and a background color.
Thierry's explanation is somewhat confusing unless you know what it means. VR3 = >00 puts a truncated 64-byte (>40-byte) color table at >0000. VR3 = >80 puts a truncated 64-byte color table at >8000.
Because there are only 64 bytes of color information, tiles 0, 8, 16, 24, ... 248 (32 tiles, aka 32 patterns or 32 characters) get their same color information from bytes 0 through 7 of the color table.
Tiles 1, 9, 17, 25, ... 249 get their same color information from bytes 8 through 15 of the color table.
The eighth group of 32 tiles 7, 15, 23, 31, ... 255 get their same color information from bytes 56 through 63 of the color table.
Note that if the pattern definition table is the full 6K, it is 3 sets of 256 tiles that get color information from the truncated 64-byte color table.
VR3 = >9F puts a truncated 2048-byte color table at >8000. Because there are only 2048 bytes of color information, tile 0 from each of the 3 sets of 256 tiles gets color information from bytes 0 through 7 of the color table. Tile 1 from each of the 3 sets of 256 tiles gets color information from bytes 8 through 15 of the color table... Tile 255 from each of the 3 sets of 256 tiles gets color information from bytes 2040 through 2047 of the color table.
What you write about the colors is correct. But the problem is that the pattern mask is dependent of the color mask except for the first two bits. If the color mask is 00XCCCCCCC111111 where 7 Cs are taken from VR3, the pattern mask becomes 00XPPCCCCC111111 where only the 2 Ps and taken from VR4 and the 5 Cs are the least significant bits of VR3. It means that if you reduce the number of colors below 256 you also reduce the number of unique patterns. As you describe your 64-column terminal emulator you used a 2K color table, which is fine, but if you go below that you cannot use a full character set.
-
3
-
-
10 hours ago, Jeff White said:You can reduce the pattern table to 2 kilobytes, color table to 64 bytes, use 8 screen image tables for scrolling the screen, and have room for sprites, file buffers, etc.
The problem with reducing the color table to less than 2K is that the masking of the colors will also affect the patterns, as Nouspikel explains:
- At the extreme, VR3 = >00 results in >40-byte tables. As there are 8 bytes per characters, this means characters are arranged in 8 groups of 32 identical characters: chars 0-7 are identical to chars 8-15, 16-23, etc.
http://www.unige.ch/medecine/nouspikel/ti99/tms9918a.htm#hybrid bitmap
-
2
-
1 hour ago, Airshack said:So the hardware knows to somehow use the one color table for all three panes?
Sounds like a reasonable compromise which allows for retaining the use of ALL Sprite’s I presume. For my understanding can you confirm the characters repeated in all three panes MUST be defined three times and appear in the same position (number) in all three panes?
Yes, if you want the same 256 patterns across the screen you must set up three identical patterns tables. But nothing will stop you from defining at least some of the patterns differently, which I did in Flying Shark for the patterns in the left side panel. The colors *will* be the same, however, so it can be a bit tricky. You enter this mode by setting VR0 = >02, VR3 = >9F and VR4 = >03.
-
4
-
-
16 hours ago, Airshack said:Surely I won't have to define 6K of character data and another 6K of color data just to exploit the advantages of Graphics Mode-II (Bit-Map)?
No you don't, you can use a hybrid mode sometimes referred to as 'half bitmap mode', see:
http://www.unige.ch/medecine/nouspikel/ti99/tms9918a.htm#hybrid bitmap
In this mode you have the advantage of bitmap mode colors but the same characters can be used all over the screen. So you only need 4 KiB VDP memory instead of 12 KiB.
The downside is that you can only use sprites 0-7. If you use sprites 8-31 they will be duplicated (JS99er is the only emulator that emulates the sprite duplication, AFAIK). If you want to avoid the duplication but save some memory, you can use 3 pattern tables but only one color table - that will use 8 KiB. Flying Shark and Titanium, for instance, are using that mode.
-
4
-
-
-
Magellan can export to an XB program. It doesn't use data compression and it doesn't include sprites, but it's probably the closest to a standard that we have.
-
2
-
-
It's been a month since my last update and a lot has happened. The change to a smaller screen since in perhaps the most noticeable, and as you can see I still haven't filled the top row with icons. Continuous music has also be added, and the tune that's playing if one I composed just today. It needs to be longer, but I'm quite pleased with its mood. For TIPI owners it will be important that you can now use the TIPI mouse instead of the joystick interface. For now you can click enemies to attack them, but the combat system generally needs a lot of work. Another improvement is that the floor and ceiling changes depending on the area of the map. There are only 2 combinations now, but there is room for four in the ROM. More data are unpacked to SAMS memory now, which is why it takes a while to start the game.
-
17
-
-
3 hours ago, jedimatt42 said:How about 50hz or 60hz as the point is the interrupt rate.
Yes, that would be my preferred option.
-
1
-
-
On 12/22/2020 at 1:30 AM, jedimatt42 said:Thanks for the TIP... I knew 9918 was a little wrong if PAL, but wasn't confident I could assert the 9929A. Then there is the NTSC 9928A, ( I think, and I don't believe that is detectable.. or matters, custom one-off mods )
9938 and 9958 can be switched PAL or NTSC, but the chip is detectable directly.
I don't think the 9928A is used in any TI model. It's either 9918A NTSC or 9929A PAL.
F18A NTSC is also misleading. To be consistent it should be F18A VGA.
-
2
-
-
34 minutes ago, Vorticon said:So in other words the pattern descriptor table could contain all the needed characters for the scrolling part as well as the matching section in the color table and all I have to do then is update the screen image table to perform the scrolling, correct?
Yes.
-
3
-
-
1 hour ago, Vorticon said:What do you mean by "updating the name table"?
I mean that you could predefine enough characters for the scrolling so you wouldn't have to update the pattern/color tables on fly.
-
1
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
TI(ny)-99/4A Computer
in TI-99/4A Development
Posted
The sprite collision issue was just a silly mistake from when a made this version a few years ago. The root cause back then was that I tried to detect the F18A and thereby changed the current status register of the v9938, so it wasn't possible to read the VDP status byte. By setting the current status register back to 0 after the detection that issue was fixed. But I made a mistake trying to change the vsync detection from cru polling to vdp status polling, which I have reverted now. I'm not sure if poling cru bit 2 always works on v9938 enhanced machines, but at least it's working on TI(ny)-99/4A. Maybe other implementations of the v9938/c9958 are connecting the interrupt line directly to the CPU? @atrax27407 is it working for you now?