Asmusr
-
Content Count
4,006 -
Joined
-
Last visited
-
Days Won
13
Posts posted by Asmusr
-
-
Version 1.8.1 is a minor update to support the generic smooth scrolling code that I will post in the 'Smooth scrolling' thread.
-
Matthew said he could imagine to write a reference implementation, but this does not mean it will be included as-is into the MAME/MESS source code. It will, of course, eventually need to be rewritten in C++.
OK, I misunderstood. But a reference implementation would also be very useful, and not only for emulation.
-
Heh. I'll write a reference, but I don't know what good it would do anyone. It would be in C/Assembly though, not C++. I don't code using an OO methodology or philosophy, and I avoid languages that support OO constructs whenever possible. Abstractions have their place, but hardware emulation is not one of them.
...
You let me know what you want in terms of a skeleton and I'll see about making it happen.
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?
-
IIRC, the random number generator was a popular item. It they are already there, so why not leave 'em and let someone "find" them?
And Kevan might need the counters to build an atomic clock!
-
2
-
-
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.
-
2
-
-
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.
-
1
-
-
Well, come to think of it... Magellan wouldn't have to output in this format. I think it would save more space (in this case, disk space for the program) if only the sections "Original character patterns", "Colorset Definitions", "Transition Character Pairs" and "Transition Map Data" would be loaded in from disk before each level starts (or even kept in RAM if some of the tables are the same for each level). Then the "Scrolled Character Patterns" (reduced to the 16 color strips mentioned above) could be generated by the TI-99 program. This would require a bit more code and, again, more RAM since some additional tables also reside there, but much less disk space and also less loading time from disk, since now, for instance, my Level 1 would only occupy about 3.3 K of data on disk. When you load in the pre-calculated 16-byte strips from disk, you still need about 5.2 K of data on disk. For a game with multiple levels this might be the way to go... in fact, from what I read in the source code, I think you're doing it a bit like this already in "Titanium" (only that you're generating the 8 distinct patterns now instead of the 16-byte strips per transition).
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.
-
1
-
-
I suggest to move LI R10,5000 outside the delay loop
-
What if, instead of including all the pre-scrolled characters for 8 possible frames (which would be 64 bytes per transition and table), you only include a 16-byte strip per transition? Since in the vertical bitmap scroller, you're copying over the whole character set each time anyway, the scroller could start anywhere between the 1st and the 9th byte of the strip, so for frame 1, you're copying over bytes 1-8, for frame 2, you're copying over bytes 2-9 etc., of course for the pattern and the color table respectively. That way, for 128 characters, you only need to store 4K of graphics data instead of 16K. Of course, the current of Magellan doesn't provide for this kind of saving the map...
Excellent suggestion, now why didn't I think of that? I will make sure the next update of Magellan can export in this format.
-
1
-
-
At this time, low priority, sorry. I have a huge number of open issues still waiting to be done before.
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?
-
I have wanted for a long time to write some 'plug and play' code that can produce a scrolling demo directly from an Assembler Transition Data export file from Magellan. This looks like is a good opportunity to try that idea.
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.
-
4
-
-
Yeah, I feel like a blooming idiot! I cannot seem to find the button to UPLOAD a .ZIP! <pathetic sigh>
More Reply Options
-
1
-
-
I have attached an update to the first post of this thread. Thank you to Marc Hull for finding the bug.
-
What new features? You mean it can get better than what YOU have already done in Scramble?!? Well, consider my mind blown! I'd love to see that too! Are you possibly one of those individual developers?
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):
-
Matthew might be a victim of his own success, changing things up might cause issues. Remember what happened when the creator of the Nano-PEB changed things up without telling anyone?
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.
-
I've not been able to get it to work either....
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.
-
1
-
-
Tried the latest Classic99 with Scramble - can't say I'm seeing any difference with the sprites
Do you have the F18A GPU enabled in the Video menu?
-
Okay, I ran into this video on You Tube today...
http://www.youtube.com/watch?v=DSfj9s6cxGY
In the video, it appears one can get true 80 columns in Extended BASIC!
I have a couple of stupid questions:
1) Is this just some kind of display only trick that one can accomplish with MLC?
2) Or can I really write a program in XB, and have a functional 80 column interactive program?
3) Assuming this actually is possible, how would I map the input locations?
It's more like a new language embedded in DATA statements in XB. There's lots of information here: http://gtello.pagesperso-orange.fr/mlc_e.htm
-
2
-
-
Well, also if not doubling the width, you could do a much better approximation of the arcade graphics than I did... the TI-99 would be capable of it, graphically. The reason why I simplified my version so much is actually the "transitions"... I imagined it to be scrolled the same way as in "Titanium", and there every transition from a character to another counts as a character to be scrolled, and there are only a maximum of about 128 transitions allowed for each level... maybe even fewer if you need static text for scores etc. This limits the complexity of the screens severely. If you do character-wise scrolling instead, the graphics might be better as well, since then you basically have full bitmap mode... as long as you can cram it into memory somehow. Even with 256 distinct characters per level, you can do much better than I did... I think in my version, each level only uses 40-50 distinct characters. I had a preliminary version (which I also attached as 1st try) where I tried to do it as faithful as possible, and there I ran out of transitions after about half a screenful of data. This one is here:
I have wanted for a long time to write some 'plug and play' code that can produce a scrolling demo directly from an Assembler Transition Data export file from Magellan. This looks like is a good opportunity to try that idea.
-
2
-
-
Rasmus suggested the Rashberry Pi ($35), and it looks interesting. And I could see many purposes for the unit - as a Super Sidecar, a Super Cartridge(s) and an all-in-one Super TIbox. The last one obviously being all emulation.
Perhaps an Arduino MEGA board would be a better choice than a RPi because it has more pins (54)? I'm not sure how they compare in performance for a project like a sidecar, and performance seems to be a critical factor.
http://www.makeuseof.com/tag/arduino-vs-raspberry-pi-which-is-the-mini-computer-for-you/
-
I'd like to see a version of Marble Madness. I know there has never been a version of it for TMS9918A based systems, so there isn't much to base it on. Or does anyone know about a similar game for the TI-99 (except for my own, rather poor attempt which I posted in the "what have you actually played" thread)? I've actually tried to put together some graphics in Magellan, but gave up because it's rather time-consuming to do the levels. Here's an example of Level 2 (trying to keep under 128 "transitions"... RasmusM will know what I mean :-)
Very nice, I would like to see it in Magellan. Is it ordinary graphics mode?
There are many nice versions out there that don't necessarily have continuous smooth scrolling.
-
I've seen the same thing as shown on the video multiple times when emulating the game in MESS 0.135. I don't know what causes that glitch to appear, but once it's there, it never goes away unless you reboot the game (that is, switch off the virtual TI-99 and restart it).
Oddly, at least with this MESS version, the F18A mode works a bit quirky. On default, it's displayed in the title screen, although I don't know if MESS supports the F18A at all. If you switch off the F18A mode, you get color corruption, that is, only the upper third of the screen displays correctly, the lower two thirds are corrupted. Sorry, don't have a screenshot of this at the moment.
MESS 0.135, that's from 2009. And it starts up in F18A mode? Very strange, the F18A wasn't even on the drawing board (as far as I know) at that time. The latest version of MESS (0.150) doesn't have any F18A support.
-
Looks like just another screen capture of Classic99 ...
... but wait, there's something strange going on.
-
4
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Classic99 Updates
in TI-99/4A Computers
Posted
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.