Asmusr

I think it's here: ftp://ftp.whtech.com/emulators/mess/roms/ti99_complete.zip

You version is also shaking for me, but when I reassemble it, it works see VERTICALRC on the disk. I'm using WinAsm99 version 3.010 and Classic99 version QI372 (and MESS 0.150). Edit: In the release notes for Win994a 3.010: The assembler application has been revised and updated to correct a problem with the resulting machine code generated by a few conditional branch op codes. Your version: 94 A056 1601 JH CHGDY My version: 94 A056 1B01 JH CHGDY Marble2.zip

I guess the comments could be more clear, perhaps include the words 'to' and 'from' If you switch off the option 'Include character numbers' you shouldn't see the PCH labels. I have never used them myself, they were added before I started to develop Magellan further. Have you tried to assemble a new object file based on your own map?

Looks nice, but like many other TI items for sale on ebay: "Does not ship to Denmark".

There's probably a problem somewhere, but I haven't found it. The strips are split into two lines each. For some of them the character transitions into itself, so the lines are duplicated. I don't see the problem in Classic99 either. Which options did you use for exporting from Magellan?

Now that I have resurrected this thread I might as well blog a little about some is the ideas I have for further developing the scrolling algorithms. My first idea is to make a game based on 2 pixel scrolling in graphics mode 1. You could store one full pattern table for each of the four frames in VDP RAM and would therefore be able to use up to 256 transitions without any performance penalty. At 60 FPS 2 pixel scrolling looks very smooth, and I think it would be great for a racing game in lines with Spy Hunter or Bump'n'Jump. My second idea is to create more variation in the graphics by paging the transitions. In its simplest form a page would equal a computer screen. Page 1 and 2 would share pattern transitions 0-63, page 2 and 3 would share transitions 64-127, page 3 and 4 would share a new set of transitions 0-63, and so on. The idea is that the previous set of transitions would just have disappeared from view when it's time to load the next. The trick would be to avoid a delay while new transitions and uploaded to the VDP (in graphics mode 1). My third idea is to take the second idea further and have a sliding window of the currently visible transitions. Magellan would have to be programmed to supervise that when one transition appears into view another one disappears, to keep the number of transitions steady. I'm not sure how the algorithm to select which transitions to upload for a given frame would work. My fourth idea is to make more usage of animations during scrolling. In Titanium I have the blinking lights, and in Scramble I have some tile based explosions, but this could be taken much further by implementing a generic system for changing some of the patterns every frame, dividing the load evenly between frames.

Here is the second version of my code that turns a generic Magellan export file into a smooth vertically scrolling demo. This is using far less memory than the first version thanks to the suggestions made by Kurt Woloch. To use the code for your own project, follow these steps: 1. Download the latest version of Magellan (currently 1.8.1). 2. Create a map in bitmap mode colors with a width of 32 characters. 3. Check that the map contains no more than 128 vertical transitions using the analyzing tool in Magellan. To reduce transitions, eliminate those with fewest occurrences first. 4. Choose Export > Assembler Character Transition Data. 5. Export with the options: Bottom to Top, Wrap Edges: off, No compression, Generate Scrolled Character Frames: 2-character Strips, Current Map Only. 6. Edit the 'Vertical bitmap scroll.a99' file and replace the file name in the COPY directive at the end with that of your own export file. 7. Add the file to a project in WinAsm99, assemble and run. There's more information inside the 'Vertical bitmap scroll.a99' file. I have chosen vertical scrolling in bitmap mode (actually half-bitmap mode) as my first example because this doesn't impose further color restrictions than bitmap mode already has. Let me know if you need sample code for horizontal scrolling or for graphics mode 1, and I will consider adding that to the 'library'. MagellanScroll-1.1.zip

For me the purpose of emulating the F18A would be to support game development. It doesn't matter much if the GPU is only running at 20%, as long as you can see that your code is working. It's nice that there is a positive difference when you run your code on the hardware. I could continue to hack Classic99 in silence and add the features I need for my own projects, but Classic is coded as a one man project and it's difficult to separate my code from Tursi's. It would be nice to be able to subclass (or whatever the C++ term is) the 9918A class for the F18A and the TMS9900 class for the GPU and slowly add the features you need until some day you have a full emulation.

Version 1.8.1 is a minor update to support the generic smooth scrolling code that I will post in the 'Smooth scrolling' thread. magellan-1.8.1.zip

OK, I misunderstood. But a reference implementation would also be very useful, and not only for emulation.

I thought the MAME/MESS framework would force you to do things certain ways, e.g. use classes for devices. And can you include assembly in MESS, I thought that would be problematic for cross platform compatibility?

And Kevan might need the counters to build an atomic clock!

I now have a version of the sample code with 16 byte strips up and running, and the performance loss appears to be insignificant. The reduced memory use makes the algorithm much more versatile, so thanks again Kurt for this suggestion. I will post the updated sample code tomorrow in the Smooth scrolling thread.

If someone (m***** ) would set up the skeleton code I think it would be an interesting project to contribute to. I would be able to recover my rusty knowledge of C++. Besides the GPU, the F18A also has two 32 bit counters running at 100 MHz (AFAIK) that I guess would be difficult to emulate accurately. If MESS renders per scanline perhaps the scanline interrupt and associated register values would not be that difficult. But for game development I think the more common VDP functions like sprites, patterns and scrolling would be much more valuable to emulate.

In Titanium I started with the raw patterns and maps and generated everything, even the transition map, on the TI on the fly. This has advantages for loading speed, but it also made it very difficult to understand what was going on. I had to look in RAM while the game was running to see which character numbers represented which transitions. This is just to explain that for 'educational purposes' I think it's an advantage to have the full data file available to look at instead of having it generated. So for my sample code I will still make an option in Magellan to export the 'strips', but once you understand the basics of how it works you can replace it with your own routine. It depends on the individual game how much RAM you're willing to sacrifice for speed. As you suggested it's also possible to generate and upload the scrolled patterns on the fly without any buffers. When I wrote Titanium I did everything the fastest way I could think of. For Marble Madness 15-20 FPS is perhaps acceptable for the scrolling. My Marble demo is running at 30 FPS and has around 10000 clock cycles left of the second frame. Another decision is whether you want to store 2 copies of the map for updating the name table - the second with the most significant bit set. Having to set the bit while copying is a significant factor for performance. I store two copies in Titanium, but in Scramble I didn't have enough RAM, but it turned out it didn't matter because it's still running at 60 FPS. In the sample code I'm also using one map only, and the VM8BHW routine is setting the MSb the fastest way I could think of.

I suggest to move LI R10,5000 outside the delay loop

Excellent suggestion, now why didn't I think of that? I will make sure the next update of Magellan can export in this format.

Sorry, I wasn't asking when you would do it, but for the overall principles for adding a device like that to MESS.

Perhaps we should have a general MESS thread for this type of question, but how would you go about emulating the F18A in MESS?

And here it is: with this modification of one of my demos you can turn your own Magellan export file into a smooth vertically scrolling demo for further development into a game. Kurt, I hope it's alright that I have used your Marble Madness graphics for the demonstration video? The map must be 32 characters wide and use bitmap mode colors. The number of vertical transitions must be less than 128. For more information, please see the notes in the 'Vertical bitmap.a99' file. Note that smooth scrolling has its price, the demo based or Kurts graphics is eating up around 16K RAM, most of which is used for storing scrolled patterns and colors. A game like Marble Madness would either have to load levels from disk or cartridge, but once the new 512K carts become readily available that shouldn't be a problem... ... and just to clarify, I'm not going to work on a Marble Madness clone myself. I haven't settled on my next game project yet, but I'm thinking in the lines of Commando/Ikari Warriors. MagellanScroll.zip

More Reply Options

I have attached an update to the first post of this thread. Thank you to Marc Hull for finding the bug.

Multi-colored tiles (up to 8 colors) and diagonal scrolling to mention a few. For the latter, take a look at Matthew's 'Rasmus scroll' demo (on a real console, please): http://atariage.com/forums/topic/207586-f18a-programming-info-and-resources/?do=findComment&comment=2676606

AFAIK Matthew hasn't changed anything, only fixed bugs. I think it would be really cool with an F18A game that used all the new features, but in the end it's up to the individual developer which hardware he wants to support. It's all about having fun while we're doing whatever we're doing.

For some reason you need to disable Interleave GPU. TI Scramble is not using the GPU except for the F18A detection. Edit: Titanium is not starting up the F18A mode either if your interleave the GPU. Edit 2: The GPU based F18A detection routine is working under the (valid) assumption that the GPU is much faster than the CPU and returns its result before the CPU has a chance to read it. Perhaps this is why it fails when you interleave the GPU Classic99? Without interleaving, the CPU is waiting for the GPU to finish. http://atariage.com/forums/topic/207586-f18a-programming-info-and-resources/?do=findComment&comment=2676863