+CyranoJ Posted January 21, 2019 Share Posted January 21, 2019 One thing is: GPU/DSP shall stop itself. Here some code from Atari: ; ; now kill the GPU ; movei #G_CTRL,r0 moveq #2,r1 .die: store r1,(r0) nop nop jr .die nop Trust me. An interrupt at the wrong time can restart that. 1 Quote Link to comment Share on other sites More sharing options...
42bs Posted January 21, 2019 Share Posted January 21, 2019 Trust me. An interrupt at the wrong time can restart that. Therefore the loop. Anyway, it is always better to leave the room clean and proper, means disable all interrupts. Else it bites you the next time you start the GPU. Still, I do not see a reason why one would stop it once started. I use it at least for OP-list update, so I let it running. Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted January 21, 2019 Share Posted January 21, 2019 Therefore the loop. Anyway, it is always better to leave the room clean and proper, means disable all interrupts. Else it bites you the next time you start the GPU. Still, I do not see a reason why one would stop it once started. I use it at least for OP-list update, so I let it running. Multiple code modules (game, menu, highscores, etc) that can be stand-alone binaries with shared ram for variables. Or a menu, loading multiple titles. 2 Quote Link to comment Share on other sites More sharing options...
SainT Posted January 21, 2019 Author Share Posted January 21, 2019 One thing is: GPU/DSP shall stop itself. Here some code from Atari: ; ; now kill the GPU ; movei #G_CTRL,r0 moveq #2,r1 .die: store r1,(r0) nop nop jr .die nop How do I print this on 3 pages to make sure I'm getting the full effect of this GPU stopping code? 10 Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted January 21, 2019 Share Posted January 21, 2019 How do I print this on 3 pages to make sure I'm getting the full effect of this GPU stopping code? Write each line as a caption of a screen capture from a popular Sci-Fi TV series. It's what all the truly "leet" coders do 4 Quote Link to comment Share on other sites More sharing options...
leech Posted January 21, 2019 Share Posted January 21, 2019 Those would've been fighting words with Sam Tramiel back in 1995. You should've seen his eyes pop out in anger at me at the Shareholder's Meeting when I questioned him about how much of a true Highlander fan he was for having licensed the rights to the relatively unknown-and-unloved animated series instead of the mega popular live-action tv series at the time... Good times! I weirdly enjoyed Highlander on the JagCD. I think it, Myst and Vidgrid were the only games I completed on the CD. My brother beat Battlemorph and Blue Lightning though. 2 Quote Link to comment Share on other sites More sharing options...
+thegoldenband Posted January 21, 2019 Share Posted January 21, 2019 Being able to play Highlander without buying a Jag CD is literally the thing I'm most excited about for this SD cart (not that I'll wait to buy one if CD support is delayed). It looks like exactly the kind of bad (or "bad") game I enjoy. I'm also looking forward to playing the upgraded version of Hover Strike, since I quite enjoyed the original. 3 Quote Link to comment Share on other sites More sharing options...
TheNameOfTheGame Posted January 21, 2019 Share Posted January 21, 2019 (edited) Yeah, I bought a Jag CD from Electronics Boutique (anyone remember them) back when the Jag was out and the sales guy was laughing at me for buying it and tried to talk me out of it. Now I'm the one crying since I sold it 10 years ago lol. So Jag CD support would be a really nice feature if it can be done. Edited January 21, 2019 by TheNameOfTheGame 3 Quote Link to comment Share on other sites More sharing options...
SainT Posted January 21, 2019 Author Share Posted January 21, 2019 Yeah, I bought a Jag CD from Electronics Boutique (anyone remember them) back when the Jag was out and the sales guy was laughing at me for buying it and tried to talk me out of it. Now I'm the one crying since I sold it 10 years ago lol. So Jag CD support would be a really nice feature if it can be done. I bought one of the launch Jaguars from EB on Oxford St. in London -- made a day trip down on the train to get it, lol. 8 Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted January 21, 2019 Share Posted January 21, 2019 How do I print this on 3 pages to make sure I'm getting the full effect of this GPU stopping code? You need to use the advanced mathematical field of numberwang - coupled with a fresh box of crayons. 3 Quote Link to comment Share on other sites More sharing options...
+orpheuswaking Posted January 22, 2019 Share Posted January 22, 2019 That's WANGERNUM Quote Link to comment Share on other sites More sharing options...
42bs Posted January 22, 2019 Share Posted January 22, 2019 Write each line as a caption of a screen capture from a popular Sci-Fi TV series. Can someone enlighten me which Sci-Fi series it is? Quote Link to comment Share on other sites More sharing options...
Rave Posted January 22, 2019 Share Posted January 22, 2019 Can someone enlighten me which Sci-Fi series it is? Battle star gallactica Sent from my TA-1012 using Tapatalk 3 Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted January 22, 2019 Share Posted January 22, 2019 The very excellent reboot, which from your question suggests you haven't seen it. If so, I HIGHLY recommend you go and watch it post haste! I got the entire blu-ray boxset from Amazon for a very low price as it's a few years old now. Awesome show, not as cheesy as the original 2 Quote Link to comment Share on other sites More sharing options...
djones60 Posted January 22, 2019 Share Posted January 22, 2019 The very excellent reboot, which from your question suggests you haven't seen it. If so, I HIGHLY recommend you go and watch it post haste! I got the entire blu-ray boxset from Amazon for a very low price as it's a few years old now. Awesome show, not as cheesy as the original I liked the original and it was something for it's day. But I like this reboot much better. Which is usual since too often they screw up the re-boots. 1 Quote Link to comment Share on other sites More sharing options...
42bs Posted January 22, 2019 Share Posted January 22, 2019 The very excellent reboot, which from your question suggests you haven't seen it. If so, I HIGHLY recommend you go and watch it post haste! I got the entire blu-ray boxset from Amazon for a very low price as it's a few years old now. Awesome show, not as cheesy as the original Battle star gallactica Sent from my TA-1012 using Tapatalk Ah. Remember Lorne Green. First time I saw the original films, I thought, "wow" Bonanza goes Star Wars Thanks for the hint. (Now we are very very off topic *ROTFL*) 2 Quote Link to comment Share on other sites More sharing options...
Hastor Posted January 22, 2019 Share Posted January 22, 2019 not as cheesy as the original That sells me on a show about as well as it would on a pizza ad Quote Link to comment Share on other sites More sharing options...
SainT Posted January 23, 2019 Author Share Posted January 23, 2019 Ok, I just found a really interesting bug. Took me a while to figure out what was going on. I'd just patched the GCC linker to correctly handle the GPU / DSP word swapped relocations and got that working, then it all seemed to just hang. But oddly, reverting the changes to the compiler made no odds. Then it took a little while to realise it wasn't actually hung, but only the first graphics object allocated was rendering. This coincided with recompiling the boot portion of the ROM, not the menu, but it was affecting the menu and not the booter. In the end it turned out that just shutting down the video processor with suitable display begin and end values doesn't stop the object processor. So it looks like the object processor had a pointer in RAM which it was running through, which was actually pointing to data being decompressed from the ROM onto RAM. So I believe the OP actually managed to corrupt the data in RAM by its writeback mechanism for keeping track of objects as they are processed. So now I've added a STOP object in ROM which I set it the OLP to, then wait a couple of frames for everything to settle, and now it runs as expected. There was a weird intermittent issue with startup for ages which went away. It may just have been luck, I have a feeling this is the main culprit. 14 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted January 23, 2019 Share Posted January 23, 2019 Ok, I just found a really interesting bug. Took me a while to figure out what was going on. I'd just patched the GCC linker to correctly handle the GPU / DSP word swapped relocations and got that working, then it all seemed to just hang. But oddly, reverting the changes to the compiler made no odds. Then it took a little while to realise it wasn't actually hung, but only the first graphics object allocated was rendering. This coincided with recompiling the boot portion of the ROM, not the menu, but it was affecting the menu and not the booter. In the end it turned out that just shutting down the video processor with suitable display begin and end values doesn't stop the object processor. So it looks like the object processor had a pointer in RAM which it was running through, which was actually pointing to data being decompressed from the ROM onto RAM. So I believe the OP actually managed to corrupt the data in RAM by its writeback mechanism for keeping track of objects as they are processed. So now I've added a STOP object in ROM which I set it the OLP to, then wait a couple of frames for everything to settle, and now it runs as expected. There was a weird intermittent issue with startup for ages which went away. It may just have been luck, I have a feeling this is the main culprit. Just one STOP object? Could you possibly expand that to three pages of code and two pages of forum text with cycle counts? Sorry - couldn't resist. So looking forward to this cart! 6 Quote Link to comment Share on other sites More sharing options...
+S.D.W. Posted January 23, 2019 Share Posted January 23, 2019 Great news SainT! Do we see a little light at the end of the tunnel? 1 Quote Link to comment Share on other sites More sharing options...
42bs Posted January 23, 2019 Share Posted January 23, 2019 Ok, I just found a really interesting bug. Took me a while to figure out what was going on. I'd just patched the GCC linker to correctly handle the GPU / DSP word swapped relocations and got that working, then it all seemed to just hang. But oddly, reverting the changes to the compiler made no odds. Then it took a little while to realise it wasn't actually hung, but only the first graphics object allocated was rendering. This coincided with recompiling the boot portion of the ROM, not the menu, but it was affecting the menu and not the booter. In the end it turned out that just shutting down the video processor with suitable display begin and end values doesn't stop the object processor. So it looks like the object processor had a pointer in RAM which it was running through, which was actually pointing to data being decompressed from the ROM onto RAM. So I believe the OP actually managed to corrupt the data in RAM by its writeback mechanism for keeping track of objects as they are processed. So now I've added a STOP object in ROM which I set it the OLP to, then wait a couple of frames for everything to settle, and now it runs as expected. There was a weird intermittent issue with startup for ages which went away. It may just have been luck, I have a feeling this is the main culprit. I do this at the beginning of my code and at the end before jumping back to menu: lea $F00000,a0 move.l d0,0.w moveq #4,d0 move.l d0,4.w moveq #0,d0 move.l d0,$20(a0) ;; set OP to STOP-OBJECT But pretty sure I saw this in some Atari example code back in time :-) 1 Quote Link to comment Share on other sites More sharing options...
+xucaen Posted January 23, 2019 Share Posted January 23, 2019 Crazy thought I just had - would it make a difference if the SD cart, once powered on, loaded the first rom it found on the SD card? My thought was that, with 1 and 2 GB SD cards being so cheep, that we could use an SD card like a cart - one rom or CD image on a card. Would the SD Cart then have better luck loading the cartridge and CD image? Anyways, yes, crazy thought. Ignore more if not worth a response. So, how 'bout them Pats? Cheers Quote Link to comment Share on other sites More sharing options...
42bs Posted January 23, 2019 Share Posted January 23, 2019 Crazy thought I just had - would it make a difference if the SD cart, once powered on, loaded the first rom it found on the SD card? If one can write to the SD card, one could load the last used ROM if e.g. A is pressed on boot, else load the menu. I'd prefer an SD card with _all_ the games and home brews 3 Quote Link to comment Share on other sites More sharing options...
SainT Posted January 25, 2019 Author Share Posted January 25, 2019 Good progress being made here. The interrupt stuff seems pretty stable now. I only enable, handle and disable interrupts from RISC code, and I've not had any odd hang-up issues on the RISC now. I also found a hardware bug in my ASIC which was causing weird behavior. The Jaguar hardware doesn't correctly de-assert the chip-selects when accessing external memory space from the RISC chips. it seems to behave OK from the 68k. I'm not sure if its because it's do contiguous reads so the external bus is saturated and the chip select doesn't get de-asserted, or if the external get is lazy and doesn't de-assert until a different address space is accessed. Either way, it meant I was getting stale data from reading a single address in a loop, so I've sorted that and it's been pretty stable. The only odd thing I am seeing now is that sometimes the RISC doesn't start. I basically have this code -- move.l #RISCGO,G_CTRL .waitStart: move.l G_CTRL,d0 and.l #RISCGO,d0 beq.s .waitStart .waitStop: move.l G_CTRL,d0 and.l #RISCGO,d0 bne.s .waitStop I've made sure the RISC is stopped before loading code and starting it up. I've added some border colour changes to see where its hanging, and its in the .waitStart loop waiting for the RISC to be running. Has anyone seen this before? 3 Quote Link to comment Share on other sites More sharing options...
SainT Posted January 25, 2019 Author Share Posted January 25, 2019 Oh, interesting. If I add instructions between the GPU start (move.l #RISCGO,G_CTRL) and the wait start loop, it appears not to start more frequently. Odd. The code can't be completing before it even detects it has started as its copying 256 bytes around. 2 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.