Jump to content

DZ-Jay

Members
  • Content Count

    13,744
  • Joined

  • Last visited

  • Days Won

    21

Everything posted by DZ-Jay

  1. To be sure, it does not seem to be a bug. My guess is that, because IntyBASIC does not really parse the assembly code following the ASM directive, it has no way of knowing if what follows is a label declaration or an opcode. It therefore assumes that everything is actual code. The alternative would be to require all statements with assembly code to leave more than one space between the ASM directive and the rest, which seems a bit brittle and unintuitive. In reality, the ASM directive was intended for single statements. More complex code should be factored out into its own module anyway. dZ.
  2. I've encountered this before. The assembler expects labels on the first column, otherwise it will interpret the string as an opcode. It seems that IntyBASIC does not inject the ASM code at the start of the left margin, and so the assembler won't accept the label. Unfortunately, it is therefore impossible to declare assembler symbols from IntyBASIC using the ASM directive. The solution is to write the code in a separate module as a normal assembly file, and have the assembler include it (instead of IntyBASIC) inline with an "ASM INCLUDE." dZ.
  3. Or my favorite, a dance remix inspired by the techno version. http://www.techunlimited.net/jworks/music/danzik.mp3
  4. The routine works by copying rows upwards, but does it continuously because the BACKTAB is an array of a single dimension. Essentially, it works like this: Starting with the first card on the second row ($214) Copy the data to the first card on the first row ($200) Increment the pointers to the next card on each row Repeat until we get to the last row. It is very efficient because the rows are contiguous in the array. That is, when the pointers reach the end of a row, incrementing them naturally makes them point to the start of the next. To copy a smaller region, a couple of things need to change: First, we need to change the starting addresses for the pointers so that they point to the correct starting and ending rows. Second, we need to detect when the pointers reach the edge of the region in order to adjust them, so that they skip the status/map panel and point to the start of the next row. The first is easy and comes almost for free: just change the addresses in the two MVII instructions at the top (the first one is the source, the second is the destination). The second one is also easy, but it incurs some cost: you will need to test that the edge of the region is reached (which requires a comparison and a branch), and if so, you will need to add the adjustment to both pointers. The point is that it does not come for free. Also, you may consider what @carlsson said, and what others (including me) have pointed out to you before: that the scrolling is too coarse and it may improved the look to scroll one pixel at a time instead. If you are still interested in modifying the routine as you requested, I can help you with the code. dZ.
  5. I thought he was looking for ideas on how to implement a “press disc to start” function. *shrug* dZ
  6. But that could catch a glitchy or bouncy signal from a different input ... -dZ.
  7. By the way, the lookup table technique is simple enough that I use it to decode the entire thing. I typically don't bother with a specialized "is disc pressed" decoder; I rather employ a full decoder that tells me what input was pressed -- which disc direction, keypad key, or action button. I first look up the input in a table for the keypad, then if that misses, I check for the disc and action buttons. As I decode, I flag which type of input it is: disc, key, button. That's a more general purpose decoder that I can apply for menus, selectors, game-play, and yes, "press disc to continue." dZ.
  8. You have to decode it. The problem is that there is no unique signal that tells you "disc is pressed"; each disc position is unique, but the signal itself is composed of various bits, and each individual bit may be part of a different input. So, the only way to tell is to decode the entire thing and then see if it is one of the disc signals. One easy way of doing it would be with a lookup table: you put all the valid disc codes in a table, then you iterate through it while comparing each element to the value of CONT. If you find a match, it's a disc input. Otherwise, it is not. dZ.
  9. That's quite clever. It is very expensive, but I is effective. I can see why this wouldn't work well for Time Pilot, since the background scenery is more fluid. Would you mind sending me a PM with the code differences between both so that I can see where the oddness lies? -dZ.
  10. No worries, I understand. I was just wondering if these were just technology experiments or if you actually had plans to complete them I'm sure it's a but of both, and like always happens with these things, the balance and priority changes all the time.
  11. I understand. The loading of GRAM will necessarily affect the timing available for the BACKTAB drawing. So if that becomes a problem, you could try to pre-load GRAM before the 8th scroll step so that it doesn't interfere with the BACKTAB copy. But you seem to have addressed it already. Ah, I see. It may depend on the way you had staggered those two. I would imagine that if the two are done right after VBLANK (i.e., after the WAIT), then it wouldn't matter, since in PAL you would have more time to copy GRAM before the STIC reads the BACKTAB data. dZ.
  12. Ah, ok. I misunderstood you. I just noticed the PAL issue on the first ROM. I tested the new one on jzIntv in both modes and works great. 👍🏻 What do you mean? In PAL mode, the CPU runs slightly faster and the vertical blanking interrupts arrive slightly later, so there is definitely a difference in timing that must be accounted for. Also, the DEFINE command in IntyBASIC only buffers the GRAM copy by setting the parameters. The actual copy happens at the top of the next interrupt. This further pushes down the rest of frame processing. Perhaps the BUSRQ fetches that the STIC performs to populate the BACKTAB are affected by this timing? Honestly, I haven't played around much with screen re-draws in PAL, but I'll investigate. By the way, is this using the same plotting routines from the Cloudy Mountain project we were working on? I tested my last build of that one in PAL and NTSC (in emulation), and it seemed to work well in both. For bullets, you may get away with it since they are usually fast and fleeting (Kai Magazine games seem to abuse this with their bullets to good effect). But for enemies it may not work that well. Perhaps a wacky idea but ... rather than having enemies overlap with clouds at arbitrary positions, how about ensuring that they can only cross at specific aligned boundaries. This can contain the error surface of overlap to a specific card or region. Then you could reserve a MOB to correct it, or manipulate the background cards at that specific location. Just a thought. Great job so far. The scrolling alone is impressive. I have to ask ... are you completing and releasing any of these projects soon? dZ.
  13. Sorry, I meant on the second binary you posted in this thread. dZ.
  14. Ah, right. What changed in this version? -dZ.
  15. Hey! I see that you're putting to use the "windowed scroll" routines to great effect. :) It looks very nice. I can't wait to see how this develops. 👍 Just one comment: It looks like the sprites are 8x8. Not knowing the constraints and trade-offs you are considering, would it be possible to make them 8x16 in double vertical-resolution to add more detail? If not, I'm sure it will still look great. -dZ.
  16. The "P" in the hat is written in German. -dZ.
  17. Thanks. I also updated the first post with a link to the first poll from 2018. Gosh, I can believe it has been almost 4 years to the day! -dZ.
  18. So far, we've got ten participants in the poll. I'm sure there are a lot more programmers. I encourage all programmers to chip in -- it only takes a few minutes. It would be neat to get the pulse of the community with regards to the current standing technology and development goals. :) Please make sure to spread the word to any other Intellivision programmers you may know that may not have visited the forum in a while. -dZ.
  19. Ah, so the large silvery areas are decorative to mask the infringing name from the box. Got it. -dZ.
  20. Well, I sure hope you have more luck (and are more disciplined) than me when it comes to the long list of "to-dos" that would follow that current never-ending project. -dZ.
  21. What silver tape? Also, does anybody know which game is ACU? I’ve never seen that title before …
  22. I was asking @evietron what they meant. I'm sure he or she can answer for themselves, thank you. dZ.
  23. What do you mean “making voice carts work”? If I plug in your device to an Intellivision console expanded with the voice module, shouldn’t it work already? dZ.
  24. Hear! Hear! Nah. I don’t even know if those qualify under “Intellivision development” anyway. Still, I think they can fall under the “historical preservation” category, no? dZ.
  25. Yeah, I was also thinking about Dave’s work as well. I would classify those under “compilers, frameworks, and other development tools.” To me, a fully integrated development environment is all of the above. At the very least, they fall under “other development tools.” dZ.
×
×
  • Create New...