8bit-Dude Posted October 26, 2017 Author Share Posted October 26, 2017 P.S: I fixed the PMG, I was still writing to hardware registers as needed for the original CIN code.Now that the OS is back on, I need to write to the shadow registers... Quote Link to comment Share on other sites More sharing options...
8bit-Dude Posted October 29, 2017 Author Share Posted October 29, 2017 Trying to do this kind of mode through a DLI per scanline is not effective, because DLIs trigger at the start of a scanline while the change needs to occur at the end, so the DLIs will eat almost all the CPU in STA WSYNC anyway. To get significant CPU back requires using an IRQ instead, as Rybags notes. Hey Phaeron, Flash helped me a lot getting the OS ROM functioning again, by following your instructions. I have attached the resulting code. But as you predicted, there is not a lot of CPU time left for anything, so FPS on my actual game is very low (3 times lower than C64). If I wanted to use IRQ, would it be a lot of effort modifying again the code? Atari-CIN.zip Quote Link to comment Share on other sites More sharing options...
Rybags Posted October 29, 2017 Share Posted October 29, 2017 Another timesaving hint for DLIs - instead of WSync you can pad out with NOPs to get a delay. You have to allow for jitter though. Also preload registers for colour changes etc. though if you're using WSync there's usually not a lot of time to do stuff. Quote Link to comment Share on other sites More sharing options...
8bit-Dude Posted October 29, 2017 Author Share Posted October 29, 2017 (edited) Another timesaving hint for DLIs - instead of WSync you can pad out with NOPs to get a delay. You have to allow for jitter though. Also preload registers for colour changes etc. though if you're using WSync there's usually not a lot of time to do stuff. I tried adding 20 nops at the beginning of the loop. The image still displays correctly (20 is the max, at 21 sync is lost). However, the FPS of the game does not improve. loop: nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop eor #$c0 sta wsync sta prior dex bne loop Edited October 29, 2017 by 8bit-Dude Quote Link to comment Share on other sites More sharing options...
Rybags Posted October 29, 2017 Share Posted October 29, 2017 Altirra debugger can also be of help, you can set traps then single-step and have a visual of what's going on, esp scanline position of current instruction. You'll probably benefit more by using a Pokey timer, but would best be served there by maximum optimization of the IRQ entry, ie use the system vector @ $FFFE. Quote Link to comment Share on other sites More sharing options...
8bit-Dude Posted October 29, 2017 Author Share Posted October 29, 2017 Altirra debugger can also be of help, you can set traps then single-step and have a visual of what's going on, esp scanline position of current instruction. You'll probably benefit more by using a Pokey timer, but would best be served there by maximum optimization of the IRQ entry, ie use the system vector @ $FFFE. Could you point me to an existing example of such programming method? I have no idea where to start with implementing this. :-S Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted October 29, 2017 Share Posted October 29, 2017 Hey Phaeron, Flash helped me a lot getting the OS ROM functioning again, by following your instructions. I have attached the resulting code. But as you predicted, there is not a lot of CPU time left for anything, so FPS on my actual game is very low (3 times lower than C64). If I wanted to use IRQ, would it be a lot of effort modifying again the code? 3x slower on a machine 1,x faster... I guess we should help here Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 29, 2017 Share Posted October 29, 2017 (edited) Using NOPs will break things on an accelerator, if that matters. Edited October 29, 2017 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
Level42 Posted October 29, 2017 Share Posted October 29, 2017 I totally cannot help as i didn't get much further than BASIc, PASCAL and C programming but: This looks like a very fun project and game....always loved Atari's Sprint arcade games. Some general thoughts that crossed my mind, please take them as positive feedback 1) the intro screen. Do we really want those muddy C64 colors ? A8 can do so much better, look at the Rastaconverter pictures.....or am I missing something about the intro screen that is special ? 2) I watched the C64 youtube video. I'm sure you have other issues now but.....that sound.......seriously drove me crazy after one minute.....I'm sure POKEY can do a lot better recreating some engine sounds.... 3) be absolutely sure to support Atari's driving control. This is the only thing that can emulate the feel of the arcade games which have proper steering wheels. This would make a great game a brilliant game IMHO. 4) It's brilliant that it will support online cross platform play....how will that work on real hardware or will this be emulator only ? 3 Quote Link to comment Share on other sites More sharing options...
Rybags Posted October 29, 2017 Share Posted October 29, 2017 Using NOPs will break things on an accelerator, if that matters. I neglected that... in the context of this game it might be worth putting a speed test in and just use a routine with WSync for accelerated CPUs. Loss of speed wouldn't be an issue, you'd probably want to put slowdowns elsewhere anyway. Quote Link to comment Share on other sites More sharing options...
Sheddy Posted October 29, 2017 Share Posted October 29, 2017 Sorry can't help at the moment either (only a few more months, please god), but love the idea. Totally agree with Level42. You're going to need a proper collaborator if you're going to use cycle sucking modes such as CIN for a few more colours, unless you want to spend a lot more time learning 6502 and the platform. As you know better than most, these vastly different 8 bit systems don't play well with generic code! 2 Quote Link to comment Share on other sites More sharing options...
8bit-Dude Posted October 29, 2017 Author Share Posted October 29, 2017 1) the intro screen. Do we really want those muddy C64 colors ? A8 can do so much better, look at the Rastaconverter pictures.....or am I missing something about the intro screen that is special ? 2) I watched the C64 youtube video. I'm sure you have other issues now but.....that sound.......seriously drove me crazy after one minute.....I'm sure POKEY can do a lot better recreating some engine sounds.... 3) be absolutely sure to support Atari's driving control. This is the only thing that can emulate the feel of the arcade games which have proper steering wheels. This would make a great game a brilliant game IMHO. 4) It's brilliant that it will support online cross platform play....how will that work on real hardware or will this be emulator only ? Please ignore that video, it is very old and not representative of the current status of the game. The C64 version is ready, and got much better FPS than shown on that old video. The sounds are also improved, etc... I have original C64 and XE at home, with ethernet cards (DragonCart in case of A8). So I am testing the game at each step on actual hardware as well as emulators. 3 Quote Link to comment Share on other sites More sharing options...
8bit-Dude Posted October 29, 2017 Author Share Posted October 29, 2017 (edited) Sorry can't help at the moment either (only a few more months, please god), but love the idea. Totally agree with Level42. You're going to need a proper collaborator if you're going to use cycle sucking modes such as CIN for a few more colours, unless you want to spend a lot more time learning 6502 and the platform. As you know better than most, these vastly different 8 bit systems don't play well with generic code! I wish I could use one the built-in gaphics modes, but they absolutely suck. I am attaching below a comparison of original track (256 colors), converted to CIN and G10, to make the point (there is also the C64 version thrown in). If someone with the needed skills could hook up with me, I would really appreciate it. Ideally, I want to run IRQs (instead of DLIs), and switch off the ROM while still having the necessary functions for the game (timers, keyboard, file reading). Edited October 29, 2017 by 8bit-Dude 3 Quote Link to comment Share on other sites More sharing options...
Level42 Posted October 29, 2017 Share Posted October 29, 2017 This is a very cool project.....I hope someone steps in !!! 1 Quote Link to comment Share on other sites More sharing options...
8bit-Dude Posted October 29, 2017 Author Share Posted October 29, 2017 (edited) In order to help veterans understand better my problems, I am attaching here the sources of a cross-platform tech demo for C64/A8. The D64 in VICE gets 32 FPS, whereas the ATR in Altirra gets 12 FPS. Could the vets (Flash? Rybags? Popmilo? Phaeron? Irgend? Schlortt?) help me improve the file /include/Atari/CIN.a65 as follows: (1) Use IRQs instead of DLI vector, to speed up the code. (2) Add refresh for timer/keyboard/joystick, so the OS ROM can be disabled? (I badly need the memory to run the full game). Many thanks in advance guyz! sources.zip demo.atr demo.d64.zip Edited October 29, 2017 by 8bit-Dude Quote Link to comment Share on other sites More sharing options...
Irgendwer Posted October 29, 2017 Share Posted October 29, 2017 (edited) I wish I could use one the built-in gaphics modes, but they absolutely suck. I am attaching below a comparison of original track (256 colors), converted to CIN and G10, to make the point (there is also the C64 version thrown in). Just my 2 € cents: especially if this is your first Atari project: keep it simple! like said: CIN is (for most users) unacceptable for a game in PAL land. So reducing the CPU load isn't the only problem... I did a very quick and rough conversion of the C64 graphics you've attached. No DLIs (yet), plain ANTIC 4. Maybe this is already sufficient.Two remarks: 1. you may have to change your player flickering logic as a DLI covers now 8 scan lines (no really a problem, vertical distribution area is just increased) 2. since the 5th colour is in use, the slicks of the cars (all missiles using the 5th colour too) would be blue according to my mock-up Hope this helps too... Edit: Silly me, there are of course DLIs due to the font changes. Thanks to the abstraction G2F delivers, I forgot this simple fact. 8bs.xex Edited October 29, 2017 by Irgendwer 2 Quote Link to comment Share on other sites More sharing options...
8bit-Dude Posted October 29, 2017 Author Share Posted October 29, 2017 especially if this is your first Atari project: keep it simple! like said: CIN is (for most users) unacceptable for a game in PAL land. So reducing the CPU load isn't the only problem... I did a very quick and rough conversion of the C64 graphics you've attached. No DLIs (yet), plain ANTIC 4. Maybe this is already sufficient. Hmmm, not that bad actually... though clearly not as good as C64 equivalent. When I stumbled on CIN, my hope was that I could achieve equivalent (or better) GFX. In the end, gameplay matters more, so perhaps in the shorterm I could latch onto this. Could you tell me how you produce the image and code to display it? P.S: the game uses pixel color to determine speed. Grey/Yellow for the track (full speed), Purple for walls (0), and everywhere else slow speed. Quote Link to comment Share on other sites More sharing options...
Irgendwer Posted October 29, 2017 Share Posted October 29, 2017 (edited) Hmmm, not that bad actually... though clearly not as good as C64 equivalent. Thanks. The C64 has surely an advantage in this field thanks to the colour ram. (So if you now discover nice in-game graphics in an Atari game, you know that the developer and artist weren't easygoing and can praise more their efforts... ) As an advantage your FPS should be now higher compared to the C64 version. In the end, gameplay matters more, so perhaps in the shorterm I could latch onto this. QFT In the end,Could you tell me how you produce the image and code to display it? For the mock-up I've used Graph2Font: http://g2f.atari8.info/ The general principle is an Antic 4 screen which is covered by characters. Since 128 characters of a single font aren't enough to cover the full diversity of your screens, the character base is changed via DLI if needed. I've attached the source G2F, you can save also the assembly code in the application and inspect that. P.S: the game uses pixel color to determine speed. Grey/Yellow for the track (full speed), Purple for walls (0), and everywhere else slow speed. I see. Easiest solution which comes to my mind would a "background-40x24-array" covering these limitations in char resolution. If you have memory left, you could just create a second bitmap matching the depiction restrictions too. 8bs.g2f.zip Edited October 29, 2017 by Irgendwer 2 Quote Link to comment Share on other sites More sharing options...
8bit-Dude Posted October 29, 2017 Author Share Posted October 29, 2017 Thanks for the input Irgend. I am going to mull over this the next couple of days, and see if it can get me progressing a little faster (I have already consummed 4 weeks of my entire freetime on this PMG/GFX stuff). Meanwhile, if some generous soul could look into ways to accelerate the CIN rendering, I would be very grateful. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 29, 2017 Share Posted October 29, 2017 I agree with Irgendwer regarding CIN on PAL machines. Aside from flickering, colours are very muted and don't really show the A8 off to good advantage. The fact this mode eats cycles is yet a further argument against its use. Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted October 29, 2017 Share Posted October 29, 2017 (edited) while I am clearly not up to speed these days might I make a suggestion... not all coders, graphists, and such make their way to this section of Atari Age... also, there is nothing wrong with trying different method of display and speed... who knows what breakthrough you will make...there are tricks and hidden ways of getting quite a bit out of the Atari... a bit of racing against the clock and doing things when you think nothings looking or doing things while the machine can't really act on it....making changes mid stride...I suggest taking this to this forum... http://atariage.com/forums/forum/51-atari-5200-8-bit-programming/ you will find yourself puled in many directions... and may even find some team mates who know what I vaguely refer to.. in the end you might find some wisdom and understanding to pull off one heck of a piece of software..... to make it shine you may find the only programming 100% shared between the two networked platforms will be the network comms between the two... and the layout... Keep a positive attitude.... more code has hit the bit bucket on the floor than has ever been put into most works, it's hard to throw away something you worked so hard to make, but then remake it completely and it's even better! you will have such gratification in that achievement that you will continue endlessly until it's as good as it can be and you let it loose in the world. Edited October 29, 2017 by _The Doctor__ 1 Quote Link to comment Share on other sites More sharing options...
8bit-Dude Posted October 30, 2017 Author Share Posted October 30, 2017 (edited) I have a quick (and important) question: does anyone know how to read MCPP files?Atari Interlace does not import ASM files for this format, only xex (see attached) MCPP.xex Edited October 30, 2017 by 8bit-Dude Quote Link to comment Share on other sites More sharing options...
8bit-Dude Posted October 30, 2017 Author Share Posted October 30, 2017 I know this is a pain, but I would like to convert the G2F code in the same manner as we did for the CIN code: OS ROM enabled, and only DLIs running. Flash, could you possibly do this for me? Please, please, please, pretty please! (see attached, g2f.a65) Atari-G2F.zip demo.xex Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.