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".