Asmusr

Only for tiles, not for sprites, right? Another question: How do you detect the F18A while avoiding detection on the current version of Classic99? Can you read the value of status reg 14, for instance? What are the standard values of the palette registers, is it the standard TI palette duplicated 4 times?

This is the inside of a switchable Editor Assembler and Disk Manager II cart that I'm thinking of buying. Can anyone see from the picture whether it can do more than that, e.g. does it have any RAM? One of the 74LS161AN chips is in a socket and is accessible from the outside. Thanks, Rasmus

I'm only flipping the buffers right after vsync. Is it possible to capture a screen shot of what you see? Perhaps Mizapf can clarify if it's possible for screen tearing effects to appear in MESS? It's been a few days since tried it on a real console, but I will do that tonight just to be sure.

Thanks. It's not a lot of video RAM, but there are actually not that many tiles or sprites in the game which is why it works so well on the TI. The hardware generated starfield explains why it's visible even through the buildings. I guess from studying the game that they also had a limitation to the number of sprites per row.

That sounds strange, and I don't see it in my MESS (0149b). Even if MESS emulated scan line rendering I don't think my program would have this problem since all screen updates are done with double buffering.

Matthew, from your experience fixing coin-op games, do you know which VDP Scramble was using? All I have been able to find is this page where it's described as 'Scramble hardware': http://www.system16.com/hardware.php?id=554 And do you know if any coin-up games were using the 9918A?

Yes that's the original font. I have decided to use that for the numbers as well.

Without the assistance of Magellan to keep track of the character transition this would be extremely difficult. And without the debugger in Classic99 it would take much longer to get the code to work. Developing in a emulation environment is so much easier and faster than on the real console, but given enough time it could have been done, of course.

I'm glad you enjoy it, Mr. Chin is Tursi's work, however. Scramble is a lot easier than Titanium because I don't have to come up with any ideas or graphics of my own, but it's still very challenging and interesting, and more rewarding because normal graphics mode leaves you with a lot of resources compared to half-bitmap mode. At the moment I just enjoy making these games so much that I will find the time. The great thing about working on retro computer games is that the target computer will never become out-of-date since it already is.

This video shows my progress so far. This is all working on the old TI - no F18A is required, only the 32K expansion. There's a slight delay when switching between maps/levels while the next map is unpacked, but no loading is required - everything is kept in memory. To prove my point I have included the demo as a cartridge file made with Tursi's makecart utility, but please try the disk instead on a real console. I have tried to keep the graphics as close as possible to the original, but if you really know your Scramble you will notice some differences where I had to move ground objects in order to cater for the TI's color set model. I also had to squeeze a few levels vertically in order to fit them on the TI screen, but I don't think this will affect gameplay. The rockets are tiles until they decide to launch, at which point they turn into sprites. The shot is made with tiles in order to prevent flickering, since the ship is already 2 sprites. It looks like they did the same in the original. The next thing is to work on the bombs... I really hope I can pull this off. I still have about half the clock cycles left running as 60 FPS, and about 8K RAM left for the program. But there is still all the collision detection and explosions to take care of. Like in the original the explosions will be done using a mixture of tiles and sprites. I'm planning to show the original 4 color sprites if an F18A is present. Enjoy! Rasmus scrambleg.bin scramble.zip

Commodore 16/Plus4: Vic-20: Sorry, have turned into a collector of bad scramble clones. And now the great Atari 7800 version: Can't beat that one on the TI, but perhaps with a little help from the F18A? ...

No problem, I will write a small Java program (30-40 lines of code) that reads 16 color palette PNG files and separates the layers into assembler DATA statements. So, how is it going with the soft firmware upgrade? (nag, nag)

You must see this! The diagonal scrolling is incredible.

That's what I hoped to hear. Clever to use the original color attribute to select the palette. Good to have this documented. So it's more forwards than backwards compatibility: you can easily display your original patterns in ECM, but designing ECM sprites that fall back nicely to standard mode is more difficult. Another easy approach to multi-colored sprites on the F18A (if you don't need a lot of sprites) is to use sprite linking: If an F18A is detected you add additional linked sprites that are extra color layers to the original sprites. Will linked sprites trigger the collision flag if they share pixels? Sure, but in full bitmap mode you don't even have two contiguous 2K blocks to use.

Hi Matthew, I'm reading this again because I'm thinking about using multi-color sprites for my Scramble game (and fall back to monochrome sprites if an F18A is not detected) but I'm not sure I fully understand how it works. Do all sprites share the same palette of 4 or 8 colors, or can each sprite use a different palette? I'm not sure what you mean by "This allows you to start off with some existing sprite or tile patterns, and expand them to support more colors at a later time in your development."? It would be nice if you could keep the monochrome sprite pattern table unmodified and just add more planes when you switch to multi-color sprites, but that's not how it works, right? You will also need to replace the first plane/table. Could a future version of the firmware include an option only to have 1K or 512 bytes between the planes? This could save a lot of RAM if you only have a few sprite patterns. Having to reserve 6k for sprite patterns would be problematic in many cases. Thanks, Rasmus

I can recommend MOD2PSG2 http://www.smspower.org/Music/Mod2PSG and Tursi's EPSGMOD player. See the demo cartridge in Classic99. I used it for the music in Titanium.

I had a console with a garbled video signal. I don't know if it was the VRAM or the 9918A that didn't work, but installing an F18A fixed it.

This store has some very reasonable prices. I bought some cartridges from him a few months ago. http://www.collectorscardsandgames.com/new/TI-994A.html#

How many of the 44 pins on the side port do you need to connect a device like the nanoPEB? If 32 pins are enough then this might work: http://www.abelectronics.co.uk/products/3/Raspberry-Pi/18/IO-Pi-32-Channel-Port-Expander-for-the-Raspberry-Pi-computer-boards From http://nouspikel.group.shef.ac.uk/ti99/pinouts.htm#Side : # Name I/O Use - ---- --- ----------- 1 VCC +5 Volts power supply 2 SBE > High if addr in >9000-94xx (sound port) 3 RESET* > System reset (active low) 4 EXTINT* < External interrupt (active low) 5 A5 > Address bus, bit 5 6 A10 > 7 A4 > 8 A11 > 9 DBIN > Active high = read memory 10 A3 > 11 A12 > 12 READY < Active high = memory is ready 13 LOAD* < Unmaskable interrupt (=> BLWP @>FFFC) 14 A8 > 15 A13 > 16 A14 > 17 A7 > 18 A9 > 19 A15 > Address bus, lsb. Also CRU output bit. 20 A2 > 21 GND 22 CRUCLK* > Inversion of TMS9900 CRUCLOCK pin 23 GND 24 PHI3* > Inversion of phase 3 clock 25 GND 26 WE* > Write Enable (derived from TMS9900 WE* pin) 27 GND 28 MBE* > Active low if addr in >4000-5FFF (card ROMs) 29 A6 > 30 A1 > 31 A0 > Address bus, bit 0 (most significant) 32 MEMEN* > Memory access enable (active low) 33 CRUIN < CRU input bit to TMS9900 34 D7 <> Data bus, bit 7 (least significant) 35 D4 <> 36 D6 <> 37 D0 <> Data bus, bit 0 (most significant) 38 D5 <> 39 D2 <> 40 D1 <> 41 IAQ > Interrupt acknowledged by TMS9900 42 D3 <> 43 VDD -5 Volts power supply 44 AUDIOIN < To sound generator AUDIO IN pin

Any news about that?

Has anyone written an assembly language LZ decompression routine for the TI? I'm thinking about compressing some game maps on the PC and decompressing them on the TI (to avoid in-game loading), so if it had a PC compression counterpart that would be great. The only utility I know about is Barry Boone's archiver, but I don't suppose that would be easy to integrate into a game?

What would it take to implement a generic solution where a Raspberry Pi is connected to the expansion port, and the PPi is programmed to emulate any number of DSR ROMs + the other functions of the nanoPEB? The price of a RPi is only half of the price of a nanoPEB and it would be much more versatile solution. I guess you would probably need one additional piece of hardware between the expansion port and the RPi. Perhaps one of the boards listed on this page could be used? http://elinux.org/RPi_Expansion_Boards I think the key is to avoid building custom hardware, if possible, but to focus on the software side that is much easier to share.

If we had a contemporary solution for SAMS, like in the next generation of nanoPEBs, I would definitely use it.

The MSX demo in post #54 (we spit on your 128K RAM ) inspired me to make this demo of a platform game. As always you should try it on a real console to enjoy the full 60 FPS smooth experience (E/A 3 DSK1.PLC). The big challenge was to coordinate the switching between vertical and horizontal scrolling. I only allow the scroll direction to change on 16 pixels boundaries since my algorithm has a 16 frame cycle. 8 pixels boundaries should be possible, but for a game where the scrolling is just aiming to center the main sprite it's not essential. Scrolling in two directions requires that you store both a horizontal and a vertical map of tile transitions. To maximize performance I also store a copy of each map with the most significant bit set on each tile. The maps are 3K each, so this totals to 12K for the maps alone. If anyone knows a really fast was to copy from CPU to VDP RAM while setting the msb let me know so I could avoid the extra buffers. I have kept the graphics in the demo very simple (only 9 tiles) in order to hold something back should I decide to turn this into a game. For now I'm more interested in working on my Scramble project. If any of you are interested in using the code for your own project just let me know and I will do my best to assist you. Rasmus Platform demo.zip