Jump to content

intvnut

Members
  • Content Count

    3,399
  • Joined

  • Last visited

  • Days Won

    7

intvnut last won the day on December 27 2016

intvnut had the most liked content!

Community Reputation

2,343 Excellent

About intvnut

  • Rank
    River Patroller

Profile Information

  • Gender
    Male
  • Location
    @R6 (top of stack)

Recent Profile Visitors

18,416 profile views
  1. I'm curious whether anyone has any questions or comments on the material. 🙂
  2. Interestingly, despite being larger, I think it would end up being slightly faster since it avoids a memory access to update the indirect pointer, if I understood the cycle count chart correctly. So, if you just have a few items at a fixed address, the larger codesize may justify the unrolled approach. Indirect access with post-increment works better in loops though, especially loops whose trip count isn't known until run-time.
  3. You should use indirect addressing with auto increment, as in this example: GADR EQU >6000 ; Address of data to read ;... LI R1, GADR ; put the address into a register MOV *R1+, R2 ; reads >6000 into R2, updates R1 to the value >6002 MOV *R1+, R3 ; reads >6002 into R3, updates R1 to the value >6004 MOV *R1+, R4 ; reads >6004 into R4, updates R1 to the value >6006
  4. If someone moved the two PSGs into an add-on board that had a programmable analog mixer, that could be interesting. (And, the default, of course, should be to mix all channels on both speakers at full.) The PSG actually has 3 analog outputs, one for each channel. With both PSGs present and a programmable analog mixer, you could do some nice stereo positioning across the 6 channels as part of sound effect or music generation. If they were granular enough, you could even have sound effects whose apparent stereo position tracks with the position of objects on the screen. That said, the Mockingboard for the Apple ][ had two PSGs with one wired to left channel, and one wired to right channel. As I said previously, you'd treat that as a 3-channel system and program different volume levels in the two PSGs to place sound effects between the two speakers.
  5. I think for a stereo mod to be worthwhile, you'd need a game written to take advantage of it properly. Otherwise, you'd just get weird separation on sound effects and music. For example, Space Patrol would have its baseline on one speaker and its drums on the other, while most of the sound effects randomly hopped between the two. A proper stereo game would likely treat the two PSGs as a 3-channel system, with different volume settings on the two PSGs to position sounds more subtly.
  6. Beamrider has some impressively unrolled kernels in its ISR (including using R6, the stack pointer, as a general-purpose auto-incrementing pointer) to blast graphics into GRAM during retrace. Treasure of Tarmin actually blanks out the top row of the display to get an extra 20 words of RAM for game variables. I always thought Defender looked and sounded awesome, even if I could never get the hang of it. Most of the original games pushed size limits on what they could afford for ROM chips. As mr_me notes upthread, the EXEC enabled more gameplay in 4K or 8K of ROM, but it held back the games themselves from really pushing the rest of the hardware to the limit. Nowadays, ROM cost is not the limiting factor, and so we can push the rest of the chips harder. Heck, when I did Space Patrol, I was hitting both ROM and cycle limits. Once ROMs got larger than 16Kx16, though, ROM stops being as much of a limit on this system. Another thing homebrews have going for them vs. games "back in the day" is that the development timeline is much more generous. It isn't "Get this game in a ROM by September to meet an October ship for Christmas."
  7. Much like Xeno's paradox, I've been asymptotically approaching a release for these documents at an ever slowing rate. I may as well push them over the line and unleash them to the world. The Locutus File System and Wire Communication Protocol document describes how to talk to an LTO Flash! cartridge over its USB serial link. If someone wants to build a 3rd party GUI or set of command line tools, this is the document that says how to do it. The Locutus Universal Intellivision Game Image (LUIGI) document describes how LTO Flash! stores game images in its internal flash, and how it unifies the BIN+CFG and ROM formats. Several folks have seen and reviewed earlier versions of these documents, including intvsteve, lathe26, Games For Your Intellivision, decle, nanochess, and others I'm sure I've forgotten. I want to thank all of my reviewers for poring over this technical material in advance of its release. Locutus_File_System_and_Wire_Communication_Protocol_V1_0_20190704A.pdf Locutus_Universal_Intellivision_Game_Image_(LUIGI)_V1_0_20190706A.pdf
  8. You don't need the @ symbol. That prevented INTVPC from printing the line in its debugger. In jzIntv, it doesn't really have any effect. Likewise for LTO Flash.
  9. If you add these sections to your CFG file, the LTO Flash GUI will apply them when sending the game to the LTO Flash unit. This is true whether you download the file to flash, or you use the immediate "Download & Play" function. So, copy stalker.bin to stalker_hack.bin, and stalker.cfg to stalker_hack.cfg, add the [macro] section, et voila. You're done. Add it to your menu or D&P and off you go. Infinite bullets.
  10. The pictures in GROM and GRAM have no color information. They are literally 1 bit per pixel—on or off. Each BACKTAB location has information about what GROM or GRAM image to display, and information on how to assign a foreground color (the "on" pixels) and background color (the "off" pixels). As for how the colors get assigned: The STIC has two display modes—color stack and foreground/background. In color stack mode, the foreground color comes from bits 0-2 of the BACKTAB entry, while the background color comes from the "color stack." In foreground/background mode, both the foreground and background colors are packed into thee BACKTAB entry; however, you're limited to just the first 64 pictures in GROM and GRAM. If you search the programming forum here for "color stack", "cstk", "foreground/background" and "fgbg", you may find some more in-depth explanations. Also, if you have jzintv, you can look in doc/programming/stic.txt for some more details. I believe I put some material up at wiki.intellivision.us as well.
  11. OK, back up a tick. There are four different things here: GROM. This is a set of 8x8 pictures stored in ROM, including the alphabet and some graphic tiles. There's 256 GROM pictures, but only the first 220 or so are interesting. GRAM. This is a set of 8x8 pictures stored in RAM, which means your program can change what the pictures are. There's 64 GRAM pictures. BACKTAB. This is the 20x12 fixed grid of characters that fills the screen. You can use pictures from both GRAM and GROM here. Each position in BACKTAB has a foreground color for "on" pixels, and a background color for "off" pixels. Every position in BACKTAB is 8x8*. MOBs. These are the Movable Objects. There are 8 of these, and they have programmable position, and to some extent, programmable size. They too can use pictures from GRAM or GROM. Each MOB may be placed in front of or behind the BACKTAB. If it's in front, its "on" pixels will cover the contents of BACKTAB. If it's behind, then the "on" pixels in BACKTAB will cover it. I've avoided using the term "card" above, as it's sometimes used to refer to a picture coming from GRAM/GROM, and sometimes used to refer to a position in BACKTAB. I think the term "card" probably is a hold-over from an earlier video chip General Instrument built that really was hard-coded for card games. (See decle's StudioVision emulator.) This is just a high level summary, but hopefully it clarifies a few things. There are games, such as Checkers, Chess, Reversi, and Backgammon that don't make much use of MOBs. (Mainly, they're used as "cursors.") ____ * Except the rightmost column, which is only 7 pixels wide. I only mention this as I know pedants are watching.
  12. Looking through the Z-Machine memory map, it's designed to allow most of the memory visible to the interpreter to be read only. That means it can live in ROM. You only need R/W access to the dynamic portion of memory. As long as a game can fit its dynamic segment in the 8000 words JLP provides (not 7999), the rest can live in ROM. JLP offers up to ~120K words (240K bytes) of game storage through page flipping. Some of that needs to hold the interpreter though. Story files that fit in the remaining space, though, should be workable. Because Z-Machine is an interpreted machine, the mapping between Z-Machine addresses and Intellivision addresses can be as flexible as needed. LTO Flash offers up to 1MB (512K words) through page flipping. It also supports Intellicart-style bankswitching, which offers 128K bytes of RAM. There is also a special LTO Flash specific mapper that's more flexible than either of those that allows mapping arbitrary portions of the external RAM into the Intellivision space dynamically in 256 word chunks. (I'm not intentionally hiding it; I just haven't gotten around to finishing the documentation, and nobody's expressed interest in a pure LTO-Flash-only game yet to drive it.) None of those requires resorting to storing data in the JLP-style flash save area. There is also expansion room in the flash filesystem to allow hanging additional data forks off of games, so if there was enough interest, I could add support for that as well. It would require extending the firmware and the GUI, but it would not be a change to the on-disk format. I've meant to release the LTO Flash wire protocol and file format docs for awhile now. I had been pushing for a 4/15 release date, but obviously didn't hit it. I think I'll just release what I've got. Perfect is the enemy of the good, I suppose.
  13. I've ported the Colossal Cave engine to the Intellivision, and I don't see why Z-Machine would be impossible. I don't know how much RAM it needs. If it needs more than what JLP provides, there's always LTO Flash. I think I looked at it once before and concluded it wouldn't fit in what I had at the time. We now have more RAM and ROM space. ZIL itself looks a bit LISP-like at first glance. There are some other languages that also target the Z-Machine. It looks like many of the Z-Machine resources listed on the Wikipedia page have fallen offline. Here's an Archive.org link to one though.
  14. If you're interested in the actual register writes to the PSG, you can put a "watch" on its registers with the command: . w1F0 1FD . If you need to watch both PSGs, also do: . wF0 FD . Of course, that's very low level, and will show you the raw values programmed into the PSGs. To make sense of them, you'll need to understand the PSG register layout. This ASCII art diagram may be useful. The numbers at the left are offsets relative to the start of the PSG. e.g. R0 is $1F0. . * * 0 Channel A Period (Low 8 bits of 12) * 1 Channel B Period (Low 8 bits of 12) * 2 Channel C Period (Low 8 bits of 12) * 3 Envelope Period (Low 8 bits of 16) * 4 Channel A Period (High 4 bits of 12) * 5 Channel B Period (High 4 bits of 12) * 6 Channel C Period (High 4 bits of 12) * 7 Envelope Period (High 8 bits of 16) * 8 Enable Noise/Tone (bits 3-5 Noise : 0-2 Tone) * 9 Noise Period (5 bits) * 10 Envelope characteristics (4 bits) * 11 Channel A Volume (6 bits) * 12 Channel B Volume (6 bits) * 13 Channel C Volume (6 bits) * 14 Controller input * 15 Controller input * * 7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0 * +---------------+---------------|-------------------------------+ * R4 | unused | Channel A Period | R0 * +---------------+---------------|-------------------------------+ * R5 | unused | Channel B Period | R1 * +---------------+---------------|-------------------------------+ * R6 | unused | Channel C Period | R2 * +---------------+---------------|-------------------------------+ * R7 | Envelope Period | R3 * +-------------------------------|-------+-----------------------+ * * Single registers: * * 7 6 5 4 3 2 1 0 * +---------------+-----------------------+-----------------------+ * | I/O Port Dir | Noise Enables | Tone Enables | * R8 | 0 | 0 | C | B | A | C | B | A | * +-------+-------+-------+-------+-------+-------+-------+-------+ * R9 | unused | Noise Period | * +-----------------------+-------+-------+-------+-------+-------+ * | | Envelope Characteristics | * R10 | unused | CONT |ATTACK | ALTER | HOLD | * +---------------+---------------+-------+-------+-------+-------+ * R11 | unused | A Envl Select | Channel A Volume Level | * +---------------+---------------+-------------------------------+ * R12 | unused | B Envl Select | Channel B Volume Level | * +---------------+---------------+-------------------------------+ * R13 | unused | C Envl Select | Channel C Volume Level | * +---------------+---------------+-------------------------------+ . I still don't have a sense, however, of the problem you're trying to solve, and whether this low-level detail is useful.
  15. What aspect do you wish to monitor? You can put a 'watch' on writes to the PSG registers in the debugger.
×
×
  • Create New...