Asmusr

Did you know Classic99 has a clock device? I didn't until a few days ago. This is how to use it: 10 OPEN #1:"CLOCK" 20 INPUT #1:A$,B$,C$ 30 PRINT A$:B$:C$

I've been struggling with how to fit the info panel (score, lives, levels) onto the TI screen, since the scrolling part must be at least 24 rows high to include all the tiles (not apparent from level 1). I even thought about turning the screen sideways as in the original (and ask users to do the same!). Now I have decided to free up two rows at the top by changing the maps slightly. This space is enough to fit in all the information while still maintaining some aspects of the original display, like the fuel bar.

Great game! I didn't quite understand the GCC part. Is it written in C, and was the ColecoVision version also written in C?

The TI does not have hardware scroll registers, so it's all done by changing tiles. The map must be transformed into one that represents the unique tile transitions rather than the tiles themselves. The transition tiles are scrolled 0-7 pixels, and then the tiles are reset and the whole screen (32x24 tiles) is scrolled one tile (8 pixels). For the latter operation the screen size matters, but the screen is only 256 pixels wide in the first instance, and my algorithm is dividing the updating of the screen evenly between frames using a double buffer approach.

The stars are just a leftover from my scrolling demo. I don't expect to keep them for Scramble.

This is just my horizontal demo applied to the Scramble graphics. The graphics transfer nicely to the TI. I had to move a few ground items to allow for the color transitions. I expect to replace the rockets by sprites is the game, but I have kept them as tiles for the demo. scramdemo.dsk.zip The file on the disk is an E/A3 object file called SCRAMO

Thanks. I guess on the TI it's 1 bpp, so I divided the numbers in the map by 2 and now it works. One more question: What do you mean by "$04 - Vertical zone of the below object ($00 if none)". Is that similar to the filling at the top or something else?

I can't seem to get the characters to match up with the map. They are supposed to fit together, right? For instance, the first 6 bytes in the map file are: 00 00 13 10 00 00 (hex), but that would make the first surface character 10 hex = blue square with a red border, if I understand your decoding instructions correctly. In MAME it looks more like it was supposed to be character 8 in your character set. Thanks, Rasmus

Thanks, but when I try to open Scramble.A78 in the editor I get an error: What could be wrong? I'm using Windows 7.

Thank you, just what I needed. With all this help I just have to make a TI version...

Doh! how did I miss that? That's very useful for extracting the tiles. Then there are the maps left. It's interesting when you look at the TileMap viewer while the game is running how the screen is built one column at a time from right to left, but the entire screen is never scrolled. I assume the hardware had scroll registers, but I still can't figure out what's going on. Is anything known about the VDP that Konami used? I noticed that in a column only the surface tile is unique, while the tiles below the surface (vertically) are all the same. Perhaps this is how the maps were stored, as a list of surface tiles and heights?

Yes I think fire + down will have to do it. Pressing space bar while holding a TI joystick seems impossible, unless you use you feet. I never playedSuper Cobra myself. How is it different from Scramble, except for the graphics? Parker Bros made a version of Super Cobra for the ColecoVision: That proves it can be done, but I was hoping to be able to improve the graphics somewhat.

I'm thinking about making a Scramble clone, with smooth scrolling graphics, of course. This is just screen shots from MAME pasted together. So I present this challenge: are any of you clever enough to extract the original graphics from the ROMs, in a format that would be useful for the TI? The above is just the first level out of five, and they managed to squeeze all this into 26 KB of ROMs, including the program. It looks like 16x16 tiles were used, and they have probably also used some kind of compression. And then there is the minor issue of how to shoot and drop bombs using a one button joystick... --------------------------------------------------------------------------- 9918A demo (emulated): F18A demo (emulated): Latest version: tiscramble-1.0.2.zip (the latest version fixes a problem with rockets appearing out of nowhere at the end of level 1, and also includes ROM images)

Just stack them like this.

Aah, I forgot you could do that. Regarding the jumper I would have preferred it to be very long so it could stick out of a hole at the back of the console :-)

More arrrgh. The bloody forum is removing everything I put after a link. This is why my last two posts look so strange.

The problem is that it's a pretty big and advanced fallback. Your entire game would have to be designed with this in mind. It eats up a lot of RAM (CPU + VDP) for buffers, and your graphics (especially for horizontal scrolling) have to be designed with very limited color and tile transitions. The mode 1 algorithm I demonstrated here <a data-ipb="nomediaparse" data-cke-saved-href="http://atariage.com/forums/topic/210888-smooth-scrolling/page-3?do=findComment&comment=2788098%20is%20somewhat%20easier%20to%20deal%20with%20than%20the%20bitmap%20mode%20algorithm,%20but%20it%20still%20eats%20up%20half%20of%20the%20VDP%20RAM%20for%20pattern%20table%20buffers,%20and%20judging%20from%20what%20you%20write%20it%20doesn" href="http://atariage.com/forums/topic/210888-smooth-scrolling/page-3?do=findComment&comment=2788098%20is%20somewhat%20easier%20to%20deal%20with%20than%20the%20bitmap%20mode%20algorithm,%20but%20it%20still%20eats%20up%20half%20of%20the%20VDP%20RAM%20for%20pattern%20table%20buffers,%20and%20judging%20from%20what%20you%20write%20it%20doesn" t%20sound%20like%20you%20want%20mode%201%20graphics."="">http://atariage.com/forums/topic/210888-smooth-scrolling/page-3#entry2788098 is somewhat easier to deal with than the bitmap mode algorithm, but it still eats up half of the VDP RAM for pattern table buffers, and judging from what you write it doesn't sound like you want mode 1 graphics. I've thought about writing some (relatively) simple examples that can take the output directly from Magellan and turn it into a scrolling demo, but I have many other more interesting ideas to spend my limited time on at the moment. The latest version of Magellan can generate both a transition tile map and scrolled patterns for you, and most importantly it can check the number of tile transitions. It would have been impossible for me to write Titanium without a tool like that. Edit: A possible fallback from the F18A smooth scrolling could be to 8 pixel scrolling, which I guess you would get almost automatically on the old hardware since you need to update the name table every 8 pixels.

Arrgh, I've seen it there many times, but never knew what it was (RTFM). I still think it would be nice to have this linked to an F18A option that also switched the GPU support on/off. When I started to write Titanium I was gladly surprised to see that it detected the F18A by the method described here http://atariage.com/forums/topic/207586-f18a-programming-info-and-resources/#entry2676863 but it would have been helpful to be able to switch it off (or is there also a secret option for that?

It just occurred to me that one of the most useful new features of the F18A is also one of the easiest to emulate, namely the lifting of the 4 sprites per line restriction. Without this restriction we could have much more colorful sprites, and on the old hardware it's easy to fall back to fewer color layers. All it would take for Tursi to emulate this would be a F18A toggle in the menu that would disable the emulation of the 4 sprites per line restriction and also enable the GPU support.

I think I should clarify that Titanium is not using any of the new capabilities of the F18A (scroll registers, multi-color sprites, co-processor, etc.). I'm only using it to bypass the sprite duplication problem that exists in half-bitmap mode in the 9918A. If the F18A is detected I know this problem is not present and I can use a 'standard' half-bitmap mode with one pattern table and one color table. If the F18A is not detected I have to use 3 pattern tables (we could call this 2/3 bitmap mode), which doubles the number of bytes that has to be sent to the VDP. Since half-bitmap mode is such a useful mode IMH), this is perhaps the easiest way to take advantage of the F18A. I would love to use some of the other features in a backwards compatible manner, so the game would still run on the old hardware, but without emulation I don't really have the time to experiment. I'm thinking about utilizing the co-processor, since this is supported by Classic99 (however, I understand that it doesn't run in parallel with the normal CPU), but I haven't got a really good idea for something it could add to game without depending too much on it.

Thank you. I don't know how I could have missed it. Edit: Very impressive. I didn't realize how difficult it must have been until a read your paper. But Pitfall was designed to work on an unexpanded console. It must be possible to cut a lot of corners if you can copy into 32K RAM.

Found the attached. I guess this is what I need? ROM Command Module 2.0.pdf

Yes it loads data both when it returns to the start screen and also between levels. I don't know how to program for ROM bank switching. Where can I read about it? I guess I wasn't clear. I was referring to your new cartridge board project, the one with the GROM emulation. :-)

Thanks. I don't suppose there is a stash of your 64K cartridge boards hidden somewhere?

True. Titanium is spending 80-90% of its time inside a CPU to VDP copying routine in scratch pad. VMCWX LI R0,VDPWD VMCWX1 MOVB *R1+,*R0 * Write byte to VDP RAM MOVB *R1+,*R0 MOVB *R1+,*R0 MOVB *R1+,*R0 MOVB *R1+,*R0 MOVB *R1+,*R0 MOVB *R1+,*R0 MOVB *R1+,*R0 DEC R2 * Byte counter JNE VMCWX1 * Check if done B *R11 How the remaining part of the game is programmed is less important for performance. Something similar should be possible from both GPL and Forth. Pure MC will always be somewhat faster, of course.