Jump to content

Photo

F18A programming, info, and resources

f18a fpga vdp 9918a 9928 video hardware mods upgrade updates

579 replies to this topic

#51 Willsy OFFLINE  

Willsy

    River Patroller

  • 3,012 posts
  • Location:Uzbekistan (no, really!)

Posted Fri Sep 27, 2013 2:38 AM

Yes, but that doesn't gain you anything, as far as I can see. Because, as you said, the address just wraps.

 

So, you write a value to a memory location, and then read it back. And? If the address wraps, then you'll always get back what you wrote:

 

If it's a 16K 9918 the address wraps, so you get back what you wrote.

If it's a xxK 9938 the address doesn't wrap, so you get back what you wrote.

 

At least, that's how I see it, unless I'm missing something?



#52 mizapf OFFLINE  

mizapf

    River Patroller

  • 2,536 posts
  • Location:Germany

Posted Fri Sep 27, 2013 3:20 AM

A safe way to tell apart 9918 and 9938/58 is to read status register 4, which has the first seven bits set to 1 (always returning FF or FE). The 9918 only has one status register, so it will ignore the status register selection and return status register 0, which is highly unlikely to return such a value.

#53 Willsy OFFLINE  

Willsy

    River Patroller

  • 3,012 posts
  • Location:Uzbekistan (no, really!)

Posted Fri Sep 27, 2013 4:38 AM

Well, for my own use, I'll only ever be looking for the F18A, so I'll use the F18GPU code execution method. I'll do it *before* I do any graphics mode/memory table initialisation and with the screen blank bit enabled. Why? Because we might have a 9918 in there, in which case the register writes to the GPU registers will cause untold havoc, which the subsequent VDP setup code will put right.



#54 matthew180 OFFLINE  

matthew180

    River Patroller

  • Topic Starter
  • 2,388 posts
  • Location:Castaic, California

Posted Fri Sep 27, 2013 10:01 AM

Why did no one respond to my way to check for what Size of VDP RAM?


The focus was more on detecting the type of VDP, not necessarily the amount of VRAM. Also, your method would not work as Willsy pointed out, so I think we were trying to understand where you were going.
 

A 9918 will just wrap any value and ignore the first byte as it only has 16K, while any other chips have more VDP RAM so will give you a write and read that shows the size.

Example: >0F (>3C00) or >1F (>7C00) or >2F (>BC00) are the same value for Screen Image table in a 9918 and on the other hand will be valid address for a 9938 or 9958.


The Screen Image Table has nothing to do with what address you write to in VRAM. You can write to any VRAM address regardless of the various VDP-table locations. The table registers are only to tell the VDP where to get data for rendering the display.

If you write to VRAM address >4000 on a 9918A with the 16K-bit set, then it will probably write to VRAM >0000. If you had said something like "write to >4001 and read from >0001...", that would have made more sense. But that still does not tell you the *type* of VDP, i.e. 9918A, F18A, 9938/58.

Also, the F18A does not have VRAM over the original 16K that is directly addressable from the host system. The extra 2K of RAM in the F18A is only addressable by the GPU, so trying to detect the F18A by trying to figure out the amount of VRAM will not work.
 

And my method will not crash a normal TI at all. It requires you only change one (1) VDP Register to find the type of VDP chip and size.


The two methods I have posted example code for will not crash a stock 99/4A either. And if you ignore probability, it could be as simple as reading a status register.

Edited by matthew180, Fri Sep 27, 2013 10:02 AM.


#55 matthew180 OFFLINE  

matthew180

    River Patroller

  • Topic Starter
  • 2,388 posts
  • Location:Castaic, California

Posted Fri Sep 27, 2013 10:23 AM

A safe way to tell apart 9918 and 9938/58 is to read status register 4, which has the first seven bits set to 1 (always returning FF or FE). The 9918 only has one status register, so it will ignore the status register selection and return status register 0, which is highly unlikely to return such a value.


Yes, but this depends on your definition of "safe". While it is unlikely that the 9918A status register would return "1111111x", it is *possible*. If you happen to read the 9918A status when the interrupt flag is set, you have five or more sprites on a line, and sprites 30 or 31 had a collision, you will get the same seven bits set.

Like I said, not probable, but possible. The methods I gave code examples for eliminate the probability. Also, reading VR4 won't help for the F18A since it uses the additional status registers for different purposes. The F18A does support an identity via SR1 though, just like the 9938/58, and could be used on a system with any of the known VDPs. But for simple F18A detection the easiest is the GPU test, or throw probability out the window and just read VDP SR1.

#56 marc.hull OFFLINE  

marc.hull

    Stargunner

  • 1,115 posts
  • Location:Oklahoma CIty.

Posted Fri Sep 27, 2013 7:29 PM

Then turn off all sprites and then read reg 4. That would cinch it but is unrelated to the original question about how to determine if a system has a 9918 or f18.

As far as Rich's memory test goes, I think that you (Rich) are not understanding that there is no 9938 or 9958 involved and the test needs to determine if the vdp is a 9918 or the f18 which look identical to the ti and more importantly its legacy software.

Matt evidently has the method to do this so we are beating a dead horse here ;-)...

#57 Asmusr ONLINE  

Asmusr

    River Patroller

  • 2,438 posts
  • Location:Denmark

Posted Fri Sep 27, 2013 10:18 PM

The only issue is that currently the simple GPU test is resulting in a false positive on Classic99 because it's implementing the GPU but not any of the other new features of the F18A, so you need an additional test to distinguish between Classic99 and a real F18A. I'm experimenting with reading SR14, the Major/Minor version status register. This returns a value like 00010011 = v1.3, which should never be returned by the 9918A status register if all sprites are turned off.

#58 matthew180 OFFLINE  

matthew180

    River Patroller

  • Topic Starter
  • 2,388 posts
  • Location:Castaic, California

Posted Sat Sep 28, 2013 10:25 AM

If you don't want to go through all the mess of setting the SAT to disable sprites and wait for VSYNC, then another method would be:

1. Unlock sequence
2. Write to VR1 to disable the interrupt
3. Read VDP status
4. Set status register to SR1 (stays on SR0 for the 9918A)
5. Read VDP status
6. Set status register back to SR0
7. Enable interrupts

SR1 is the identity register and returns:

 0 1 2   3 4 5     6        7
 1 1 1 | 0 0 0 | blank | horz_int
For the 9938/58, bit-2 will never be set, so you can determine a 9918A, F18A, 9938, 9958 with this method.

#59 Manic1975 OFFLINE  

Manic1975

    Chopper Commander

  • 151 posts
  • Location:Croatia

Posted Sat Sep 28, 2013 12:38 PM

Matthew how can I update my F18A to ver 1.5? Update here is 1.4 and on your web page is 1.5.

Please help!!!



#60 InsaneMultitasker OFFLINE  

InsaneMultitasker

    Stargunner

  • 1,710 posts

Posted Sun Sep 29, 2013 12:15 AM

Yes, but that doesn't gain you anything, as far as I can see. Because, as you said, the address just wraps.

 

So, you write a value to a memory location, and then read it back. And? If the address wraps, then you'll always get back what you wrote:

 

If it's a 16K 9918 the address wraps, so you get back what you wrote.

If it's a xxK 9938 the address doesn't wrap, so you get back what you wrote.

 

At least, that's how I see it, unless I'm missing something?

 

VRAM address wrapping will not work as you suggest.  In the TI, the 9918's VRAM is accessible from 0x0000-0x3fff.   In both the TI and Geneve, 9938/58 Video RAM is visible in 16K windows or pages, also accessible from 0x0000-0x3fff.

 

To access memory beyond the initial 16K, video register #14 corresponds to the three high order address bits (A14,A15,A16) necessary to change the visible page.  64K expansion RAM (which increases total VRAM from 128K to 192K) is accessed with an additional status register bit.

 

The programmer can detect total VRAM memory using a simple algorithm to read/write/test a byte across the pages.  However, as already noted in this thread, total video RAM does not equate to the VDP type (9938, 9958, 9918, etc).   Also, non-9918 video modes will auto-increment A14-A16, flipping the VDP address to the next VRAM page.  This can wreak havoc in DSRs using high VDP to store the last accessed filename.  



#61 --- Ω --- OFFLINE  

--- Ω ---

    TI-Runner

  • 10,490 posts

Posted Tue Oct 1, 2013 7:13 PM

Matthew, is this the gadget required to do updates to the F18A?
http://rover.ebay.co...=item20d6015e69
 
If so, it seems rather inexpensive with free shipping and all.

#62 matthew180 OFFLINE  

matthew180

    River Patroller

  • Topic Starter
  • 2,388 posts
  • Location:Castaic, California

Posted Tue Oct 1, 2013 9:17 PM

I would have to say no. That looks like an Altera programmer. The F18A uses a Xilinx FPGA. You can get one and try if you want, but that is up to you. If the programmer does not specifically say "Xilinx" and "supports IMPACT" then it probably won't work. The cheapest one I have found is the Digilent HS1:

http://www.digilenti...2&Prod=JTAG-HS1

And it looks like they increased the price from $49 to $54. In the future I might have some other alternatives, but don't ever hold your breath for a hardware project.

Edited by matthew180, Tue Oct 1, 2013 9:18 PM.


#63 RXB OFFLINE  

RXB

    River Patroller

  • 2,765 posts
  • Location:Vancouver, Washington, USA

Posted Wed Oct 2, 2013 3:29 AM

Seems like the F18 does not follow any standard that every other VDP system for the TI used.

 

So I guess this is discussing the F18 vs everything else made. That is fine for the F18 but does leave everything else to hang out to dry.

 

It is a F18 thread so my view to be compatable was not much use. It would be nice if some standard could be found.



#64 --- Ω --- OFFLINE  

--- Ω ---

    TI-Runner

  • 10,490 posts

Posted Wed Oct 2, 2013 8:35 AM

I would have to say no.

 

Okay, thanks Matthew.  It's not really like I needed programmer (at least at the moment).  At that price I thought it might be handy to have one around in case it was ever needed.  I guess I'll pass for now.

 

I've still not gotten around to installing mine yet either!   I do want to thank you though, for devoting so much time and effort into designing and building that little gem.  From what I've read that little device of your has made quite a few people VERY HAPPY!  I know I will be too.  :)



#65 matthew180 OFFLINE  

matthew180

    River Patroller

  • Topic Starter
  • 2,388 posts
  • Location:Castaic, California

Posted Wed Oct 2, 2013 8:50 AM

Seems like the F18 does not follow any standard that every other VDP system for the TI used.


What "standard" are you talking about?

So I guess this is discussing the F18 vs everything else made. That is fine for the F18 but does leave everything else to hang out to dry.


To the contrary, my example code will work on any 99/4A system with any VDP and tell you if you have a 9918A, F18A, or 9938/58. I don't see how that leaves everything else out to dry?

It is a F18 thread so my view to be compatable was not much use. It would be nice if some standard could be found.


Again, what "standard" are you talking about? If you think it would be nice to find a standard, then do so. I've made my attempt and presented it here, but you did not seem to like my solution.

#66 RXB OFFLINE  

RXB

    River Patroller

  • 2,765 posts
  • Location:Vancouver, Washington, USA

Posted Wed Oct 2, 2013 4:00 PM

To access VDP RAM on a 9938 or 9958 with the devices like TIM Card, AVPC, and other cards all have the same access to VDP RAM. (these all have the same standard)

 

I realize the F18 is not like the others so therefore does not work the same way. Just pointing out the obvious. 

 

You did a remarkable job of creation of a new hardware device.

 

It just requires a new way to access it.



#67 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,777 posts
  • HarmlessLion
  • Location:BUR

Posted Wed Oct 2, 2013 4:03 PM

Accessing the 16k of VRAM on the F18A is done the same way as the 9918A. It doesn't have expanded RAM like the 9938 or 9958.



#68 RXB OFFLINE  

RXB

    River Patroller

  • 2,765 posts
  • Location:Vancouver, Washington, USA

Posted Wed Oct 2, 2013 4:08 PM

I ment of course the extra RAM the F18 has.

Or as you guys call it the GPL RAM.

 

That access subroutine is not like all the other cards.

All the cards made have the same access standards for regular 16K VDP RAM in Graphics Mode 1. 

But access to extra RAM is standardized in 9938 and 9958 cards.



#69 --- Ω --- OFFLINE  

--- Ω ---

    TI-Runner

  • 10,490 posts

Posted Wed Oct 2, 2013 7:57 PM

Hey All,

Excuse me for butting in, especially since I'm not a programmer.  But the first three things that came to my mind when reading this thread were, "So what?", "Who gives a rip?"  and "Big freaking deal!"

 

1st - 95% of the people who buy this device will NEVER have a reason, cause, or need access that so-called "GPL RAM"

2nd - The F18A appears functionally compatible with the 9918A, 9938 and 9958 devices.

3rd - It appears to run ALL legacy software, so what's the big deal?

4th - Only one person that I know of on the planet seems to have an issue with what appears to be a truly trivial matter.

5th -  Like Tursi said, it was not designed to have expanded RAM like the 9938 or 9958 devices.

6th - That "GPL" RAM is just a bonus if you want to play with it (if I understand correctly)  It's not an advertised feature.

 

A) In my reading of these forums, I've seen a lot of these older RARE cards (that still work), cost a FREAKING FORTUNE. Matthews card is truly affordable, (hey, I bought one if that tells you anything).   If it were not for Matthew and his F18A, the majority of us would not  have decent quality output for our "Real Iron" boxes.

 

B) There are routines that have been developed to scan for what type of card is in use, so in the future *IF* anyone wishes to exploit this "GPL RAM", they can learn it, just like they learned BASIC, Assembly, FORTH or that other rarely used language on the TI, while remaining compliant with the other cards.

 

I guess the old adage is true, "No matter how great something is, you can't please everyone."  As for me, I SEE NO ISSUE HERE.



#70 matthew180 OFFLINE  

matthew180

    River Patroller

  • Topic Starter
  • 2,388 posts
  • Location:Castaic, California

Posted Wed Oct 2, 2013 9:57 PM

I ment of course the extra RAM the F18 has.
Or as you guys call it the GPL RAM.


I called the extra 2K of RAM "GRAM" or GPU-RAM because it was only accessible by the GPU. I realize this conflicts with the term GRAM that is related to GROM, so I typically spell out "GPU RAM" in an attempt to be less confusing. Then again, TI never produced GRAM...

That access subroutine is not like all the other cards.


What access subroutine?

All the cards made have the same access standards for regular 16K VDP RAM in Graphics Mode 1.


As does the F18A. And by the way, the graphics mode has NOTHING to do with accessing VRAM.

But access to extra RAM is standardized in 9938 and 9958 cards.


Standardized to what? Itself? The "cards" have nothing to do with it, they all used the same VDP (9938 or 9958) so of course access to the extra VRAM was the same on all of them.

I suppose not making the extra 2K of RAM available in the same way that the 9938/58 make their extra RAM available is different. But it is only 2K after all, and it did not seem logical to add just one extra address bit to one of the original eight VDP Registers. That would be a pain in the ass for a programmer to manage, and the extra bit would make you think there was an extra 16K, so it would just add additional confusion. However, I would hardly call the 9938/58 way of doing anything "standard", since there was nothing else to compare them with.

Heck, if you want to go that far, the 9938/58 are not compatible with the 9918A and did not follow its "standard" simply due to the fact that the 9938/58 have more VDP Registers. The 9938/58 also violate *all* the unused bits of the original eight VDP registers by using them to hold the expanded address bits, extra interrupt bits, extra mode bits, etc. The 9938/58 also don't have a "lock out" to prevent poorly written 9918A/9928/9929 software from crashing on them. The 9938/58 are only "software" compatible with the 9918A, and only in cases where the original software followed *all* the 9918A rules (which a lot of software does not as I found during my testing, and which ultimately lead to needing to add the lockout).

I would argue that the F18A is more "standard" to the original 9918A than the 9938/58 are. And that was my goal, to make the F18A a 100% hardware and software replacement for the 9918A. The enhancements are just added features that must be enabled before they can be used or affect the operation of the F18A.

The 9918A only has 16K of VRAM, and so the F18A only lets you access 16K of VRAM from the host system. If you want access to the "non-standard" memory above 16K, then you have to use the GPU. If you want to use the VRAM above 16K on the 9938/58, then you have to set up "non-standard" VDP Registers and additional address bits.

But ultimately we were talking about detecting the F18A vs the 9918A, and since the F18A is designed to look exactly like the 9918A from the host system's perspective, detecting the F18A is not a simple task. It is the same problem you have in trying to detect if your code is running on an emulator or real hardware. Unless the emulator gives you a "non standard" way to detect the emulator, then your software will never know and can't detect the emulator. If Tursi allowed you to detect Classic99 from code, would you call his emulator "non standard"?

You seem to have gotten bent out of shape that writing to a memory address higher than >3FFF on the F18A would not allow you to detect the F18A. The fact that you can't access the extra 2K by writing to an address over >3FFF without it wrapping is because the F18A works just like the 9918A, and therefore the F18A is "standard".

#71 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,777 posts
  • HarmlessLion
  • Location:BUR

Posted Thu Oct 3, 2013 5:24 PM

I was sort of thinking about that naming scheme... maybe the GPU's 2k could be called a GPU Cache to alleviate naming confusion? ;)

 

Anyway, I think the F18A is a fantastic, drop in replacement. Most of the concerns people have had have come from those expecting not a drop-in replacement for the 9918, but an upgrade. If you think about the F18 as a 9918, Rich, it will make a lot more sense to you. Because of its design, you can safely ignore everything else and it will work just like the original VDP, except that it attaches to a VGA monitor. :)



#72 Willsy OFFLINE  

Willsy

    River Patroller

  • 3,012 posts
  • Location:Uzbekistan (no, really!)

Posted Fri Oct 4, 2013 2:12 AM

Yep. That's the way to think of it. It means you don't have to use a crappy TV or knackered 20 year old CRT monitor any more. Just throw them out. Just use a modern TV with VGA input or a PC LCD monitor.

 

Of course you can unlock the F18A with a special sequence and go bananas with all the extra features if you want ;-)



#73 RXB OFFLINE  

RXB

    River Patroller

  • 2,765 posts
  • Location:Vancouver, Washington, USA

Posted Fri Oct 4, 2013 3:46 PM

I was sort of thinking about that naming scheme... maybe the GPU's 2k could be called a GPU Cache to alleviate naming confusion? ;)

 

Anyway, I think the F18A is a fantastic, drop in replacement. Most of the concerns people have had have come from those expecting not a drop-in replacement for the 9918, but an upgrade. If you think about the F18 as a 9918, Rich, it will make a lot more sense to you. Because of its design, you can safely ignore everything else and it will work just like the original VDP, except that it attaches to a VGA monitor. :)

The F18 is a great device, but I have RGB monitors and they work great for my normal TI hardware. 

(My RGB monitors have a Composite input so I have a VGA sized monitor the conversion is built in)

What happened to that Box that converted the TI Composite to VGA monitors?


Edited by RXB, Fri Oct 4, 2013 3:48 PM.


#74 OLD CS1 OFFLINE  

OLD CS1

    River Patroller

  • 3,844 posts
  • Technology Samurai
  • Location:Tallahassee, FL

Posted Fri Oct 4, 2013 4:37 PM

What happened to that Box that converted the TI Composite to VGA monitors?

 

I will have to find it, but in my thread where I was working on (and stopped working on) S-Video from the 9928, I found what Tursi had, that many of these cheap converters cannot handle the non-interlaced signal.  StarTech has a device which I confirmed with their engineers (great pre-sale support!) that it synchronizes to interlaced and non-interlaced (progressive) composite input.



#75 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,777 posts
  • HarmlessLion
  • Location:BUR

Posted Fri Oct 4, 2013 7:00 PM

Besides that, the quality will never be as good. You are still starting with a composite (or, at best, component) video signal and upscaling it, as opposed to the F18A generating the VGA natively. That was what ultimately led to me abandoning that concept as well. :)

 

You'll find that those 15Khz RGB monitors will be harder and harder to find in working order, and the availability of those VDPs is not good enough to be any help to people who don't already have them. F18A is a good forward-looking solution, not just for the TI, but for all the systems that use the TMS9918A.







Also tagged with one or more of these keywords: f18a, fpga, vdp, 9918a, 9928, video, hardware, mods, upgrade, updates

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users