Asmusr

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?

How about this? sabrewulf-v9938.rpk sabrewulf-v9938-8.bin

Does this help? sabrewulf-v9938.rpk sabrewulf-v9938-8.bin

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.

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.

Here you are. SPRDUP.dsk sprdup08.bin sprdup.a99

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.

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: js99er-20210102233328.webm

That was fast 🙂. I will try to copy what you did.

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.

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?

test.a99

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. TEST.dsk test8.bin 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.

What would you expect the value of R1 to be after running this code? LWPI >8300 STWP R0 MOV *R0+,R1 I would have expected >8300, but according to a bug report for js99er the correct value is >8302.

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.

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

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.

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.

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. https://magellan.js99er.net

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. texcaster.rpk texcaster8.bin

Yes, that would be my preferred option.

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.

Yes.

I mean that you could predefine enough characters for the scrolling so you wouldn't have to update the pattern/color tables on fly.