Jump to content

matthew180

Members
  • Content Count

    2,890
  • Joined

  • Last visited

  • Days Won

    3

matthew180 last won the day on August 13 2019

matthew180 had the most liked content!

Community Reputation

2,034 Excellent

5 Followers

About matthew180

  • Rank
    River Patroller

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Central Florida
  • Interests
    My family, FPGA, electronics, retro/vintage computers, programming, coin-op games, reading, outdoor activities.
  • Currently Playing
    Divinity2, Borderlands2, beta-testing for Realms of Antiquity (TI-99/4A CRPG).

Recent Profile Visitors

20,288 profile views
  1. AI is 14 cycles, SWPB is 10 cycles, so 24 cycles total. This assumes register addressing to make it comparable to shift, since the shift can only operate on registers. The shift instructions have two forms (three actually, but only two that apply here), using R0 for the count, or the count is a fixed value. If the count is in R0, then the timing is 20+2N (N is the value read from R0). So in this case it would be 20+2*8 = 36 cycles. If the count is fixed (which is encoded as part of the instruction), then the timing is 12+2C. So in this case it would be 12+2*8 = 26 cycles. So, AI + SWPB is still faster, by at least 2 cycles, than shifting by 8.
  2. You might want to check out the 9900 datasheet and get a little familiar with the instruction timings (pg. 28). The slowest instructions are: DIV, MPY, Shift instructions, XOP, LDCR/STCR, BLWP. The barrel shifter takes a cycle for each bit-shift, so the more bits, the longer the instruction takes. So, even though shifting is faster than DIV and MPY for powers of 2, it is still slower than other instructions if you can do the same task with other instructions.
  3. It is always a challenge since everyone's install, retro computer, etc. will be different. I let the size and cost factors take priority here, and it should also make modding and installing easier (fewer holes to get exactly lined up, etc.)
  4. That is just a slight optimization to the VDP routines, and you only incur a small increase (8us or something like that) by using other methods. I see you worked it out, even if it is backwards (i.e. written in Forth). This has been debated and tested quite a bit on the 99/4A, and IIRC there is only one very specific situation where you might be able to overrun the VDP (again, on the 99/4A). Then again, I think that one case was on a modified system, so it is probably not possible on a stock console. The threads about it are here on A.A. if you want to dig around. The main clincher (again, IIRC) for the 99/4A is that VDP access triggers the wait-state generator, so you pretty much cannot overrun the VDP. Also, if the system has an F18A, it cannot be overrun on the retro computers that used the 9918A family of VDP. You need a CPU clock around 25MHz or faster to overrun the F18A.
  5. See Lee's reply above (2nd response to your question).
  6. This was an unfortunate era for TI, since they were numbering the bits in their bytes and words (16-bit backwards from the rest of the industry). You can find internal memos where engineers complain about this, and TI did finally come around (not sure when, but I suspect they were not doing this for very long). Sadly the TMS9900 CPU and 9918A VDP were caught up in the reverse bit numbering. It is important, as other mentioned, to realize that is the *ONLY* the numbering that is reversed, and not the bit-values. Bit-value goes up from right-to-left, just like they always have, and just like decimal numbers. Basically this: 128 64 32 16 8 4 2 1 Bit *place value*, MSbit is always on the left 0 1 2 3 4 5 6 7 TI bit *numbering* duing the 9918A era 7 6 5 4 3 2 1 0 Bit numbering for the rest of the industry ------------------------ 1 1 1 0 0 0 0 0 = >E0 The MSbit is always on the left in both numbering schemes, and the "endian" of the 9900 CPU, while important to know when programming in assembly, has nothing to do with the bit numbering. To help prevent errors, I find when working with the 9900 and 9918A that using the bit-value (or "weight") prevents ambiguity. For example: TI bit-2 would be bit >40 (0010 0000) TI bit-5 would be bit >04 (0000 0100) TI bits-2..4 would be bits >38 (0011 1000) Specifying the bit positions this way works no matter how they are "numbered".
  7. That is pretty cool. It makes me wonder what the graphics subsystem capabilities for Zaxxon are. One thing the arcade games typically have over home computers is, more ROM in the CPU memory map, and a graphics subsystem that can read directly from those ROMs. What they typically do not have (talking classic arcade game era here) are relocatable video tables and redefinable patterns. The 9918A's ability to relocate the various tables in VRAM actually adds to a lot of complexity, and I always wondered what the actual benefits are?
  8. Like the 9918A, the F18A's internal address register is truly 14-bits, and the wrap-around is just a natural function of the hardware. To let the VADR (VDP Address Register) continue to address memory over >3FFF would require an extra address bit (not a huge deal, maybe), but then that address bit should probably also be made accessible via VREG (VDP Register) to accommodate the future changes that will come with the MK2 (and to make them as compatible as possible). The MK2 will need 5 more address bits, the MK1 will have 1 extra address bit (and memory over 18K or 20K will probably wrap). I can't remember where the 9938 put the extra address bits, but it was in a low VREG IIRC (I will look it up later). This *might* be a change I can introduce early, but I will want to have at least worked out all the design details first, of how it will ultimately work for compatibility with the MK1 and MK2, and where the GPU memory-mapped devices will go.
  9. "private to the GPU" just means, like a lot of the design, I should have thought about it a little more, thought about future expansion of the memory space, and / or had a few more discussions on the forum about it. It is totally possible to have a little more VRAM for the original F18A, but now I have to figure out how to do it without breaking everything (existing F18A software, mostly) all to hell, where to put the new required address bit(s) (ideally the same place the 9938 added them), when to enable the extension to retain 9918A compatibility, and where / how to move the GPU memory-mapped devices (VRAM regs, the DMA, etc.) out of the VRAM address space.
  10. The knock-off programmers just extracted the license info from the USB ROMs, so for sure it will not prevent 3rd parties from making programmers that work the the Xilinx tools. I think it is crap that Xilinx even tries to lock this down. Oh, and that 2mm header, yeah, you can thank Xilinx for that too... Although, for as much bitching as I do about these annoyances, I do have to say that from a technical standpoint, the Xilinx FPGAs and the documentation are absolutely fantastic, and one of the main reasons I stick with them. I have spent a lot of time evaluating a lot of the alternatives, and always end up back with Xilinx for reasons related to packaging (physical IC), features, cost, and capabilities. They also make their tools available for free for use with the low-end FPGAs (which are the only ones hobbyists can afford anyway). The Lattice FPGAs are designed primarily to be small and lower capability, and the Altera (Intel now) FPGAs are all higher-end, expensive, and very large. Xilinx has FPGAs that fit right in the middle (and also go up to the high-end capabilities too), and are still the only option for the cost, size, and features needed for the MK2 (I did a reevaluation just the other night).
  11. I have seen this happen occasionally with devices that take control of the console at power-on, for example my CF7+ sometimes causes problems at power on when it hijacks the power-on sequence to put its text on the master title screen. I'm not sure of the dynamics going on, since the F18A powers-up in a locked mode. But, if it gets unlocked, then all bets are off.
  12. Most of the failures I have seen have been breaks of the wire where it is soldered into the DB-15 connector. You can slide the plastic shell down the ribbon cable to expose the wires and check visually. I have not seen the ribbon cable itself break due to bending or anything, it is braided wire and pretty flexible. The pigtail is available from http://www.pccables.com part number 07129, "VGA HD15F to IDC16". I know it is inconvenient, but that is the only source of this kind of cable I could find, and one of the reasons the MK2 will use its own cable and header.
  13. Yeah, I think we started talking about this as something I would have to address with the MK2, and then unfortunately I was side-tracked with the whole "H", "D", "M", "I" issue. So, it was pretty short-sighted of me when I made the VRAM over 4K private to the GPU. That will probably change, even with the original F18A firmware, to make what is "private" GPU VRAM accessible via the VDP Address Register, but only when the F18A is unlocked (for compatibility reasons). I also want to try to squeeze a little more VRAM out of the original F18A by not being so casual with the Block-RAM I used for line buffers (it might provide an additional 2K of VRAM, but no promises). Also, mapping the VDP registers into the VRAM address space was also short-sighted, and something will have to change in the MK2 related to that. I think I worked it out a few years ago (holy shit it has been a long time!), but I did not write it down, so I'll have to go through the mental process again.
  14. @ralphb Sorry I missed all the posts about the amber screen. I really don't think that is the F18A directly, but rather the VGA pigtail cable. I have come to learn that the pigtails are not very well made and the connections break easily. If the problem is on the F18A board, then almost certainly it will be with the resistors that make up the DAC. All of these problems are pretty easy to test / troubleshoot if you are comfortable with a multimeter and / or soldering iron. The 4x display is possible on the F18A by setting the mode bits to a value > 9, IIRC (I'll have to check the HDL again). It is not intentionally supported by the hardware, so anything that happens in this mode is not guaranteed.
  15. This is the hack that has been around for a while to get things working on Windows 10. It does work, mostly, although I do have times when ISE will fail on the very last step of building a bitstream where is refuses to write the data to the disk. No amount of software restarting, project file clean-up, or system restarting will get it working. But go away for a few hours, come back, run again, and *poof* it works fine! It is very frustrating, and one of the biggest bullshit decisions Xilinx ever made! Xilinx did not end the Spartan-6 (or 3 for that matter) FPGAs, but the totally dropped support for the software needed to write HDL for them (and they did this right when Windows 10 was coming out). Also, IIRC, IMPACT tries to identify the JTAG programmer, and basically uses a license string that they sell to licensees that goes into the USB ROM on the device. Again, total bullshit, because there is nothing special about the Xilinx programmer (other than the ridiculous cost), or the licensed programmers. Digilent is a licensee, so their JTAG programmers work with the Xilinx tools and are much more reasonable in cost. And no, I don't think you needed to jump through the DLL swapping hoops to use IMPACT, but I don't remember for sure. They make a "tools" download that is smaller (1GiB, IIRC, if you can call that small) that contains just the programming software like IMPACT, so that is all that is really needed to just load the bitstream. At some point I do plan to write my own bitstream loader, but it has never come to the top of the project stack yet.
×
×
  • Create New...