JohnPCAE Posted April 4, 2013 Share Posted April 4, 2013 (edited) I dug up an old demo I tried to write a long time ago that attempted raycasting on the Inty. Unfortunately, it flickers on real hardware and I can't find the source to it Anyhow, here are the files I was able to find. The .rom file works in Nostalgia, and I recall trying it on an Intellicart (it ran, but with the aforementioned flicker). Anyhow, maybe it will be useful to someone...Regards,John raycast_20151012.zip Edited October 12, 2015 by JohnPCAE 1 Quote Link to comment Share on other sites More sharing options...
intvnut Posted April 4, 2013 Share Posted April 4, 2013 You might try running this in a recent jzIntv with the debugger and history tracking enabled. When the history tracker's enabled, it will detect all sorts of glitch inducing problems and help you zoom in on them. If you hit '?' you'll see it also has some checkers you can enable to look for dropped STIC and GRAM writes. The biggest culprit is too many non-interruptible instructions in a row. Shifts and MVOs are the two most common classes of non-interruptible instruction. jzIntv hints to me that that's your biggest issue, actually. In the following excerpt, I just enabled history logging and dropped STIC write detection: NON_INT = 83 at PC = $53A8 NON_INT = 83 at PC = $53A8 NON_INT = 83 at PC = $53A8 STIC CTRL WR drop: addr = $0028 @4429620 (data $0000) PC = $52DF Prev STIC CTRL window ended @4423421; next window approx @4435454 STIC CTRL WR drop: addr = $0029 @4429629 (data $0000) PC = $52E0 STIC CTRL WR drop: addr = $002A @4429638 (data $0000) PC = $52E1 STIC CTRL WR drop: addr = $002B @4429647 (data $0000) PC = $52E2 STIC CTRL WR drop: addr = $002C @4429656 (data $0000) PC = $52E3 STIC CTRL WR drop: addr = $002D @4429665 (data $0000) PC = $52E4 STIC CTRL WR drop: addr = $002E @4429674 (data $0000) PC = $52E5 STIC CTRL WR drop: addr = $002F @4429683 (data $0000) PC = $52E6 NON_INT = 72 at PC = $52E7 NON_INT = 72 at PC = $52F0 NON_INT = 72 at PC = $52F9 NON_INT = 72 at PC = $5302 NON_INT = 72 at PC = $530B NON_INT = 72 at PC = $5314 NON_INT = 72 at PC = $531D NON_INT = 72 at PC = $50F7 NON_INT = 83 at PC = $53A8 NON_INT = 83 at PC = $53A8 NON_INT = 83 at PC = $53A8 NON_INT = 83 at PC = $53A8 STIC CTRL WR drop: addr = $0030 @4492212 (data $0000) PC = $52DF Prev STIC CTRL window ended @4483157; next window approx @4495190 STIC CTRL WR drop: addr = $0031 @4492221 (data $0000) PC = $52E0 STIC CTRL WR drop: addr = $0032 @4492230 (data $0000) PC = $52E1 STIC CTRL WR drop: addr = $0033 @4492239 (data $0000) PC = $52E2 STIC CTRL WR drop: addr = $0034 @4492248 (data $0000) PC = $52E3 STIC CTRL WR drop: addr = $0035 @4492257 (data $0000) PC = $52E4 STIC CTRL WR drop: addr = $0036 @4492266 (data $0000) PC = $52E5 STIC CTRL WR drop: addr = $0037 @4492275 (data $0000) PC = $52E6 NON_INT = 72 at PC = $52E7 NON_INT = 72 at PC = $52F0 NON_INT = 72 at PC = $52F9 NON_INT = 72 at PC = $5302 NON_INT = 72 at PC = $530B NON_INT = 72 at PC = $5314 NON_INT = 72 at PC = $531D NON_INT = 72 at PC = $50F7 NON_INT = 83 at PC = $53A8 NON_INT = 83 at PC = $53A8 NON_INT = 83 at PC = $53A8 NON_INT = 83 at PC = $53A8 STIC CTRL WR drop: addr = $0038 @4545582 (data $0000) PC = $52DF Prev STIC CTRL window ended @4542893; next window approx @4554926 STIC CTRL WR drop: addr = $0039 @4545591 (data $0000) PC = $52E0 STIC CTRL WR drop: addr = $003A @4545600 (data $0000) PC = $52E1 STIC CTRL WR drop: addr = $003B @4545609 (data $0000) PC = $52E2 STIC CTRL WR drop: addr = $003C @4545618 (data $0000) PC = $52E3 STIC CTRL WR drop: addr = $003D @4545627 (data $0000) PC = $52E4 STIC CTRL WR drop: addr = $003E @4545636 (data $0000) PC = $52E5 STIC CTRL WR drop: addr = $003F @4545645 (data $0000) PC = $52E6 NON_INT = 72 at PC = $52E7 NON_INT = 72 at PC = $52F0 NON_INT = 72 at PC = $52F9 NON_INT = 72 at PC = $5302 NON_INT = 72 at PC = $530B NON_INT = 72 at PC = $5314 NON_INT = 72 at PC = $531D NON_INT = 72 at PC = $50F7 NON_INT = 83 at PC = $53A8 NON_INT = 83 at PC = $53A8 NON_INT = 83 at PC = $53A8 NON_INT = 83 at PC = $53A8 NON_INT = 72 at PC = $52E7 NON_INT = 72 at PC = $52F0 NON_INT = 72 at PC = $52F9 NON_INT = 72 at PC = $5302 NON_INT = 72 at PC = $530B NON_INT = 72 at PC = $5314 NON_INT = 72 at PC = $531D NON_INT = 72 at PC = $50F7 NON_INT = 83 at PC = $53A8 NON_INT = 83 at PC = $53A8 NON_INT = 83 at PC = $53A8 NON_INT = 72 at PC = $52E7 NON_INT = 72 at PC = $52F0 NON_INT = 72 at PC = $52F9 NON_INT = 72 at PC = $5302 Too many non-interruptible instructions will cause the display to jump. The actual threshold is somewhere around 60. Also, the STIC registers are only available for about 2900 cycles after the interrupt gets asserted. It looks like you're copying in a shadow of what you'd like in the STIC, but you're doing it late in your ISR. This is what I called "VBlank Period 1" in the Intellivision Wiki. http://wiki.intellivision.us/index.php?title=VBlank_Period_1 Quote Link to comment Share on other sites More sharing options...
JohnPCAE Posted April 4, 2013 Author Share Posted April 4, 2013 It's too bad I lost the source, though there isn't all that much code in it. I ran it through dasm1600 and figured a few things out: 5000-5800: code A000-B1FF: data (trig tables?) B800-B8FF: data (the first 16 words defines the maze: 1-bit, 16x16 bitmap, 1=solid, 0=empty) Quote Link to comment Share on other sites More sharing options...
JohnPCAE Posted April 5, 2013 Author Share Posted April 5, 2013 (edited) For what it's worth, attached is what a night of reverse-engineering my own binary gave me... raycast_demo_src.txt Edited April 5, 2013 by JohnPCAE Quote Link to comment Share on other sites More sharing options...
JohnPCAE Posted April 7, 2013 Author Share Posted April 7, 2013 I don't know if anyone is even interested, but here's an updated source (though I haven't figured everything out yet, and my memory is pretty hazy). It seems to me that at least some parts of it could be hugely optimized. raycast_demo_src.txt 2 Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted April 7, 2013 Share Posted April 7, 2013 Looks great! I have one question. The lag during movements, is that due to the computations, or was that self-imposed as a delay? -dZ. Quote Link to comment Share on other sites More sharing options...
JohnPCAE Posted April 7, 2013 Author Share Posted April 7, 2013 Most likely due to computational lag, though I think I have throttling code somewhere in there that loads only a few GRAM cards on each VBLANK since there isn't time to load all 64 at once. Quote Link to comment Share on other sites More sharing options...
JohnPCAE Posted April 14, 2013 Author Share Posted April 14, 2013 Here's an updated source with the render() routine fully reverse-engineered... raycast_demo_src.txt 1 Quote Link to comment Share on other sites More sharing options...
JohnPCAE Posted April 14, 2013 Author Share Posted April 14, 2013 One more...reformatted so it assembles cleanly with as1600. It produces exactly the same binary as the original. Regards, John raycast_demo_src.txt 2 Quote Link to comment Share on other sites More sharing options...
+nanochess Posted April 14, 2013 Share Posted April 14, 2013 One more...reformatted so it assembles cleanly with as1600. It produces exactly the same binary as the original. Regards, John First time ever I've seen assembly source code for Intellivision. Interesting! 1 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted April 14, 2013 Share Posted April 14, 2013 First time ever I've seen assembly source code for Intellivision. Interesting! So interesting that you are tempted to code for it? 1 Quote Link to comment Share on other sites More sharing options...
JohnPCAE Posted April 15, 2013 Author Share Posted April 15, 2013 Almost fully reverse-engineered now. I don't understand the code that reads the controllers...maybe I lifted it from a cart? I don't remember. Anyhow, it's at the point where it's probably safe to try improving it. raycast_demo_src.txt 2 Quote Link to comment Share on other sites More sharing options...
+nanochess Posted April 15, 2013 Share Posted April 15, 2013 So interesting that you are tempted to code for it? I'm a little lazy about getting an Intellivision and a proper Flash cartridge. Quote Link to comment Share on other sites More sharing options...
JohnPCAE Posted April 18, 2013 Author Share Posted April 18, 2013 Fixed the rendering glitches along the cardinal directions (N, S, E, W) and fixed some code comments... raycast_demo_src.txt 1 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted April 18, 2013 Share Posted April 18, 2013 You might want to consider adding a *.rom (or *.bin+*.cfg) to new updates so that people who are not familiar with the SDK1600 can try it it out too. Quote Link to comment Share on other sites More sharing options...
Fushek Posted April 18, 2013 Share Posted April 18, 2013 Just downloaded this ... very cool stuff. Reminds me of playing an old time dungeon crawl (ala Bard's Tale). I kept expecting a wandering monster to pop up! Quote Link to comment Share on other sites More sharing options...
JohnPCAE Posted April 19, 2013 Author Share Posted April 19, 2013 (edited) You might want to consider adding a *.rom (or *.bin+*.cfg) to new updates so that people who are not familiar with the SDK1600 can try it it out too. Hmm, I guess you have a point. Here's a ZIP with source and executables. I also improved the rendering performance a bit. raycast.zip Edited April 19, 2013 by JohnPCAE 1 Quote Link to comment Share on other sites More sharing options...
JohnPCAE Posted April 19, 2013 Author Share Posted April 19, 2013 Bleh. Here's another one that fixes some more drawing glitches. It also adds a new feature to play with: Keypads 1-9 will change the maximum viewing distance (1 units to 9 units). Any other key will set it to the maximum viewing distance, which is the default. raycast.zip 1 Quote Link to comment Share on other sites More sharing options...
JohnPCAE Posted April 19, 2013 Author Share Posted April 19, 2013 I think I fixed the flicker problem...I was putting cart RAM at the same location as the STIC shadow. The flicker at least in the emulator seems to be gone once I moved the RAM. I also sped up the rendering. I get different results in Nostalgia vs. jzIntv during rendering, but the same once rendering is finished. I'm wondering what this does on real hardware... raycast.zip 1 Quote Link to comment Share on other sites More sharing options...
JohnPCAE Posted April 22, 2013 Author Share Posted April 22, 2013 Optimized the multiplication algorithm a bit, but it's too bad we don't have something like an Intv Harmony cart to take over the computational load raycast.zip 1 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted April 22, 2013 Share Posted April 22, 2013 Optimized the multiplication algorithm a bit, but it's too bad we don't have something like an Intv Harmony cart to take over the computational load You might find these features of intvnut's JLP Rev 02 interesting. Quote Link to comment Share on other sites More sharing options...
JohnPCAE Posted April 25, 2013 Author Share Posted April 25, 2013 That certainly might help. I managed to squeeze a little more speed out of the fixed-point multiply and divide routines, but they might be pretty near maxed-out now. I even took a stab at a table-based approach to multiplication but it looks like my ultra-unrolled version outperforms it. raycast.zip Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted April 25, 2013 Share Posted April 25, 2013 Looks good. It seems to have an occasional visual glitch in jzintv but I can try it out on PAL later. Will it eventually become a game or is it just going to remain a tech demo? Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted April 25, 2013 Share Posted April 25, 2013 You might find these features of intvnut's JLP Rev 02 interesting. The problem with the hardware-accelerated math routines is that they are only available in the JLP firmware, not even in the emulator. However, I believe that Joe, Arnauld, and Carl were each working on optimizing a multiplication routine in the INTVProg mailing list, some time ago. I further believe that Carl's version was accorded as the most efficient in the general cases. I'll try to to look it up and post it here. -dZ. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted April 25, 2013 Share Posted April 25, 2013 The problem with the hardware-accelerated math routines is that they are only available in the JLP firmware, not even in the emulator. However, I believe that Joe, Arnauld, and Carl were each working on optimizing a multiplication routine in the INTVProg mailing list, some time ago. I further believe that Carl's version was accorded as the most efficient in the general cases. I'll try to to look it up and post it here. -dZ. Sorry, I found the thread in my mailing list archives, but it was regarding the computation of square roots, not multiplication/division. -dZ. 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.