Asmusr Posted September 5, 2013 Author Share Posted September 5, 2013 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 7 Quote Link to comment Share on other sites More sharing options...
RXB Posted September 5, 2013 Share Posted September 5, 2013 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 changes between vertical and the 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 The only way I see this advancing further is to add more memory to the TI by using the SAMS to store the 12K could be increased to 900K. (900K/12K = 75 times more map) At that point you have a hell of a map and still have 100k left over for the program. (100K/32K = 3 times more program space) Quote Link to comment Share on other sites More sharing options...
Willsy Posted September 5, 2013 Share Posted September 5, 2013 Wow Rasmus you are a kick-ass coder! 1 Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted September 6, 2013 Share Posted September 6, 2013 The only way I see this advancing further is to add more memory to the TI by using the SAMS to store the 12K could be increased to 900K. (900K/12K = 75 times more map) At that point you have a hell of a map and still have 100k left over for the program. (100K/32K = 3 times more program space) Well there is still another possibility. You could store the map in The cartridge space ROM. 64K EPROM allows quite a big map. You could still use the 32K RAM of the PEB. Ofcourse developing for the cartridge space can be a bit frustrating as you have to deal with bank-switching and would be emulator only until you can burn it onto eprom. Quote Link to comment Share on other sites More sharing options...
Asmusr Posted September 6, 2013 Author Share Posted September 6, 2013 The only way I see this advancing further is to add more memory to the TI by using the SAMS to store the 12K could be increased to 900K. (900K/12K = 75 times more map) At that point you have a hell of a map and still have 100k left over for the program. (100K/32K = 3 times more program space) If we had a contemporary solution for SAMS, like in the next generation of nanoPEBs, I would definitely use it. Quote Link to comment Share on other sites More sharing options...
RXB Posted September 6, 2013 Share Posted September 6, 2013 (edited) If we had a contemporary solution for SAMS, like in the next generation of nanoPEBs, I would definitely use it. The biggest advantage to the SAMS is the amount of memory it takes to switch banks. In RXB it takes zero as I built it into RXB. As for Assembly it takes no Lower 8K support routines to be loaded to access and switch memory blocks. The entire Assembly routine is less then 48 bytes to switch any memory to any memory pages or blocks. Besides any Cart RAM memory are not compatible with normal EA or XB or any other cart unlike the SAMS that can be used my most carts. Including TF or REA or EA or RXB or XB or LOGO or PASCAL or Mini Memory. Edited September 6, 2013 by RXB Quote Link to comment Share on other sites More sharing options...
Willsy Posted September 6, 2013 Share Posted September 6, 2013 TF supports the SAMS "out of the box" by means of the >MAP command. Quote Link to comment Share on other sites More sharing options...
+acadiel Posted September 6, 2013 Share Posted September 6, 2013 Well there is still another possibility. You could store the map in The cartridge space ROM. 64K EPROM allows quite a big map. You could still use the 32K RAM of the PEB. Ofcourse developing for the cartridge space can be a bit frustrating as you have to deal with bank-switching and would be emulator only until you can burn it onto eprom. Or better yet, the new 512K ROM cart. Imagine what you could put in there. The copy from cart ROM to VDP or 32K to execute is very fast (it shocked me when I did it with Never Lander the first time on a real system). All you have to do is write to an address segment to select an 8K segment, roll a loop to read and copy the data, and do it again if you need more. If RXB is aware of it, and we could mix some of the XB ROM space with some of the bank switched ROM space (without XB crashing due to lack of some of its ROM routines), we could probably build in some pretty nice support stuff directly into the 512K ROM space for use with XB as well. Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted September 6, 2013 Share Posted September 6, 2013 The biggest advantage to the SAMS is the amount of memory it takes to switch banks. In RXB it takes zero as I built it into RXB. As for Assembly it takes no Lower 8K support routines to be loaded to access and switch memory blocks. The entire Assembly routine is less then 48 bytes to switch any memory to any memory pages or blocks. Besides any Cart RAM memory are not compatible with normal EA or XB or any other cart unlike the SAMS that can be used my most carts. Including TF or REA or EA or RXB or XB or LOGO or PASCAL or Mini Memory. Unfortunately SAMS is not all that prevalent and a game written solely for it will have a small audience. I would think that using extra memory like SAMS as a storage place for information on disk - so that the program could call it from memory instead of disk - would be a nice method to implement. A standard setup could pull from disk; an advanced setup could use the memory. Many ways to skin the cat... 2 Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted September 6, 2013 Share Posted September 6, 2013 A standard setup could pull from disk; an advanced setup could use the memory. Many ways to skin the cat... Very true. Also with many people having switched to virtual disks in emulators like Classic99, using Nano's or CF7's or even other solid state drive replacements for legacy devices, speed is already improved in the 'standard setup' already. Quote Link to comment Share on other sites More sharing options...
Asmusr Posted September 6, 2013 Author Share Posted September 6, 2013 Or better yet, the new 512K ROM cart. Any news about that? Quote Link to comment Share on other sites More sharing options...
+acadiel Posted September 6, 2013 Share Posted September 6, 2013 Any news about that? I'm comfortable with the ROM part. Tursi can speak to where he is with GROM, and the manual is pretty darn comprehensive. (I'd like to get XB and RXB working on it for a PoC.). Once Tursi is done, it just needs a sponsor or sponsors to get them made and sold. At that time, I can help provide guidance. Matthew got the last batch done, so he can provide input as well. Quote Link to comment Share on other sites More sharing options...
RXB Posted September 6, 2013 Share Posted September 6, 2013 A patch to allow for RXB to reside and use the 512K cart from XB is easy as GPL does not need access to the ROMs for anything except specialized routines like math or XB only commands. Now moving data into and out of the RAM of the cart would required Assembly as all routines in XB or RXB must use the ROMs to fetch or save variables. So even a CALL LINK would fail to work. As would RXB CALL MOVES or CALL LOAD or CALL PEEK in that all of them use the XB ROMs to access any variable. Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted September 7, 2013 Share Posted September 7, 2013 Perhaps RXB could be set up with a prototype of the 512K cart. That way the RXB software could be tuned and delivered with the 512k carts when it becomes generally available. Kinda like RXB being the killer application that pushes the amount of orders. I mean I am sure that the 512k would do fine without RXB, but it would be very nice that when the hardware becomes available there is some cool software available for it. Quote Link to comment Share on other sites More sharing options...
Tursi Posted September 7, 2013 Share Posted September 7, 2013 I'm comfortable with the ROM part. Tursi can speak to where he is with GROM, and the manual is pretty darn comprehensive. (I'd like to get XB and RXB working on it for a PoC.). Once Tursi is done, it just needs a sponsor or sponsors to get them made and sold. At that time, I can help provide guidance. Matthew got the last batch done, so he can provide input as well. The GROM is done and has been for a while. The loader is nearly done, and I'm back on that.. well, right now actually. Just resolving a DSR issue (yep! It's biting ME now. ) We do have to figure out how the initial AVR programming will be done... I suppose I can do a number of them. Quote Link to comment Share on other sites More sharing options...
+acadiel Posted September 7, 2013 Share Posted September 7, 2013 The GROM is done and has been for a while. The loader is nearly done, and I'm back on that.. well, right now actually. Just resolving a DSR issue (yep! It's biting ME now. ) We do have to figure out how the initial AVR programming will be done... I suppose I can do a number of them. I wouldn't mind doing the AVR initial programming for any planned board runs. My 844USB programs them well and has a "repeat" button on it. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted September 8, 2013 Share Posted September 8, 2013 The GROM is done and has been for a while. The loader is nearly done, and I'm back on that.. well, right now actually. Just resolving a DSR issue (yep! It's biting ME now. ) We do have to figure out how the initial AVR programming will be done... I suppose I can do a number of them. Tursi why not put the DSR in GROM like a phoney device. It could load anything anywhere when called. My old RXB PDISK used the Lower 8K as a storage device. I also wrote another that used the 8K of the VDP as a storage area for the EA Cart to load a Supercart for switching RAMs in the Cart. Except I know that everyone wants to use a non GPL compatible DSR Link all the time like a ROM only DSR Link with Assembly only access. To bad it just make the project more impossible. Quote Link to comment Share on other sites More sharing options...
Tursi Posted September 8, 2013 Share Posted September 8, 2013 Putting aside the bitter half.. My problem isn't the DSR itself, it's the DSRLNK I'm using in my library. For some reason the problem /I/ have is that my DSRLNK works on Classic99 and doesn't do jack on hardware. I found one bug yesterday and fixed that, but just a little more digging is needed. Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted September 9, 2013 Share Posted September 9, 2013 Putting aside the bitter half.. My problem isn't the DSR itself, it's the DSRLNK I'm using in my library. For some reason the problem /I/ have is that my DSRLNK works on Classic99 and doesn't do jack on hardware. I found one bug yesterday and fixed that, but just a little more digging is needed. If ya would like another set (or sets) of eyes to help find the problem, feel free to post the code... Quote Link to comment Share on other sites More sharing options...
Willsy Posted September 9, 2013 Share Posted September 9, 2013 And, picking on Rich's rant , any DSRLNK should include a search for GPL DSRs. It would be very cool to ship an entire cart with a virtual device in it - that would be possible with an appropriate DSRLNK that, say, searches the GROMs in the event that a ROM search doesn't find a matching device. That would be super-neat! I'm planning to play with GPL this winter - doing too much guitar work at the moment, including building an electric guitar from scratch... Quote Link to comment Share on other sites More sharing options...
Tursi Posted September 9, 2013 Share Posted September 9, 2013 Ideally, all that is needed to do that is to use the DSRLNK in the console. Thierry's page has some notes on how to do that, I will probably put that into my library. Tim, thanks for the offer! I've got the tools I need to troubleshoot now, since it's been a mystery I've wanted to solve for about a year now. If I'm still stuck I will definitely pop it online to ask. Quote Link to comment Share on other sites More sharing options...
matthew180 Posted September 14, 2013 Share Posted September 14, 2013 Rasmus Inspired Scroll Demo ** Submitted with permission from Rasmus to use his graphics and map. The rasmus_scroll.zip file contains an F18A version of the early scroll demo Rasmus did that eventually turned into his game Titanium. The F18A version uses the hardware scroll registers to pixel-scroll a tile screen in both the horizontal and vertical directions. A joystick is required and the fire button does not do anything. The GPU is used to block-copy the tiles up or down one tile-row after 7-pixles of vertical scrolling. It is also possible for the whole screen to be scrolled before adjusting the tile data, but this is completely up to the designer. The GPU can copy the VRAM data 2-bytes at a time since it has direct 16-bit access to the VRAM, and the GPU also runs with a 100MHz clock so it is very fast. ECM3 is used to get the same color depth as the GM2 bitmap mode that the original demo used, although ECM3 provides much more flexibility in color use since any pixel in the tile can be any of eight colors. The ship was ripped from the ROM data (including the palette) of a popular coin-op video game from the 80's, so maybe you will recognize it (no, it is not Xevious, although that is one of my favorites too). Classic99 was used for testing up until ECM3 was enabled, since Classic99 has the GPU implemented (and helped me find a bug in my GPU-copy code!) Classic99 does not have the scroll register support (at the time of writing this), but I could see the tile copy taking place and it was very cool since I had totally forgotten that Tursi had added some initial F18A support. The nice thing about using the scroll registers is that the 9900 still has lots of time (and memory) to run a game rather than pixel scrolling. Still, what Rasmus did with the stock 9918A is incredibly impressive! Sorry for not posting a video, I don't have my camera set up. rasmus_scroll.zip Quote Link to comment Share on other sites More sharing options...
Asmusr Posted September 15, 2013 Author Share Posted September 15, 2013 Rasmus Inspired Scroll Demo You must see this! The diagonal scrolling is incredible. Quote Link to comment Share on other sites More sharing options...
TheMole Posted September 16, 2013 Share Posted September 16, 2013 You must see this! The diagonal scrolling is incredible. That quite the tease... I'd love to see it in action, but my hardware isn't installed yet and probably won't be for a couple of months. Hoping for a kind soul to make a video of it . Quote Link to comment Share on other sites More sharing options...
ti99iuc Posted September 16, 2013 Share Posted September 16, 2013 (edited) Wow, it's a very nice piece of programming... :thumbsup: it seems like that ti99 will be ready to have his first DEMO SCENE soon ...good job guys... i love your work and passion :lust: because you are the energy that our TI99 needed to live. Thank you !!!you are GREAT ! ------------------------------EDIT:here is a fast Video using my Android Phone: http://youtu.be/Fnlx7tXXZkY Edited September 16, 2013 by ti99userclub Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.