F18A programming, info, and resources

[matthew180]

There is no "key" for the "green screen", since as Tursi mentioned it is simply the default data loaded in VRAM when the F18A powers up, and you usually never see it because the computer initializes the VDP and VRAM before your human eyeballs can see it. If the computer does not "power up" properly and initialize the VDP / VRAM, then you will see the F18A "green screen" (as it has been called).

 

If you ran the update program and it just resets the computer, then that means it did not load from disk correctly. The first thing the program does when it runs is a checksum of itself, and if that fails it reboots the system. You can update an F18A to the same version it is already running, the updater will not prevent you from doing that. Your problem is that the updater program itself is not loading without error.

[+arcadeshopper]

There is no "key" for the "green screen", since as Tursi mentioned it is simply the default data loaded in VRAM when the F18A powers up, and you usually never see it because the computer initializes the VDP and VRAM before your human eyeballs can see it. If the computer does not "power up" properly and initialize the VDP / VRAM, then you will see the F18A "green screen" (as it has been called).

 

If you ran the update program and it just resets the computer, then that means it did not load from disk correctly. The first thing the program does when it runs is a checksum of itself, and if that fails it reboots the system. You can update an F18A to the same version it is already running, the updater will not prevent you from doing that. Your problem is that the updater program itself is not loading without error.

 

This happened to me on my nanopeb, turned out to be the nano trying to init before the f18a was ready, the manufacturer knows of the bug and I ended up getting mine replaced with one that has a delay before init to give the f18a time ..

 

Greg

[Wildstar]

Yea RGB monitors are still being made today.

 

The color is just so much better then what VGA can to do. VGA was designed for TEXT while RGB was designed for GRAPHICS and COLORS.

 

http://www.dpreview.com/news/2013/2/14/Dell-releases-UltraSharp-monitors-with-99percent-Adobe-RGB-color-space-support

 

 

VGA is just cheaper for a good reason.

 

VGA is ANALOG RGB that runs at 31KHz+ HSync.

 

VGA refers to a graphic format like CGA not the actual monitors which were Analog RGB like Amiga analog RGB but using a smaller 15 pin DE15 connector similar in dimensions to the 9-pin COM port (RS232) connectors. Amiga's Analog RGB was running at 15 KHz and some of them are "Multisync" for 15Khz to VGA compliant 31KHz or higher HSync video.

 

CGA is just Digital RGB or RGBI monitors.

 

The monitors that commonly have composite video in those days like seen on Commodore 8-bit (Commodore 128/128d.... RGBI [digital] at 15 KHz) and Amiga which commonly used ANALOG RGB at 15 KHz and easily allowed AMIGA computers to genlock to TV.

 

Most LCD TVs or LED LCD TVs which have composite video have a simple scanline doubler of some sort built into the monitor in order for viewing TV video on the LCD screens which are VGA level natively. They don't internally drop down to 15 KHz on the LCD mondule. It needs a 31Khz video or higher so the composite video input passes through an upscaler or scanline doubler components of cheap quality level. It is not the same as a framebuffered upscaler system used for better quality video conversion.

 

You only find true 15 KHz monitors as CRTs and they are usually used for special purpose and because of the low production of these antique technologies, it costs a fortune. Where a few LCDs that do exists with CGA compatibility (digital RGB at 15 KHz HSync support) are digital.

 

You can convert it to analog RGB by bypassing the DAC. At least in the old days. It might not be as easy today if it's integrated onto a singular IC. If you have a DAC component, you can usually bypass the DAC and send analog R,G, and B lines directly with maybe only some set of resistors for correct Ohm for clear analog RGB. You'll mostly find them in some forms of POS equipment (Point of Sale) and what not.

 

Modern VGA is for text, video graphics, etc. After all, that is what any modern PC GUI environment is going to be. Technically, modern LCD monitors (VGA/SVGA) is a multisync monitor for multiple video modes in the VGA/SVGA/XGA/etc. with HSync from 31KHz and higher HSync as required for different screen resolution level. The VSync are often variable on most monitors because they can range from 50 Hz to 240 Hz. Those that are higher VSync are usually specialized CRTs used in medical and other similar equipment.

 

Just so people know, VGA is clearly about graphics.... it is what the G stands for. So is CGA... was.

 

Enough said.

Edited October 28, 2014 by Wildstar

[Tursi]

I like your description Wildstar, except for the fourth "composite" raster beam, I've never heard of such a thing. All color CRT monitors I know of (from Televisions to HD VGA) use red, green and blue guns, and black and white monitors use a single gun. (in general, note that the gun itself does not set the color - it's the phosphor that it strikes which glows color.)

 

Are you thinking about a special 4-channel monitor of some sort? Any link to that?

[Wildstar]

You're right. Anyway, it's been awhile.

 

I'm waiting for the F18A to arrive. I edit the above to reduce any confusion. I look forward to the F18A's and getting back into doing some good ol' programming for the TI-99/4A.

 

I have the PEB and have the Black & Silver model TI's and the Beige. I like to use one of my two Black & Silver units. Only one PEB, though.

Edited October 28, 2014 by Wildstar

[+OLD CS1]

I searched this topic for "clock" and did not turn up an answer. I remember it mentioned that a setting in the F18A would change the GROM clock, which would also change the range of the 9919. What is that setting, and what would allow me to get a one octave drop from the 9919? Would the tone codes be the same just one octave lower, or would we need to calculate a new table?

Edited October 28, 2014 by OLD CS1

[matthew180]

Yes, the F18A can slow down the GROM Clock and modify the system's sound frequency range. I know I have posted the information, I'll see if I can find it.

[+OLD CS1]

Yes, the F18A can slow down the GROM Clock and modify the system's sound frequency range. I know I have posted the information, I'll see if I can find it.

 

::rubbing hands together:: Exxxxxcellent...

[Wildstar]

Let me understand a few things....

 

The F18A is not only a FPGA based enhanced "TMS9918A-based" VDP which is in its own right somewhat of a modified TMS9900 IIRC... running at 100 MHz. I think I read somewhere that it also has a 100 MHz TMS9900 "co-processor". When reading some threads and all, I hear this so called "GPU".... is that referring to the VDP itself or the "100 MHz TMS9900 co-processor" (also on the same very FPGA).

 

I'm trying to understand that bit a little bit better.

 

I also read it has 32 Bit 100 MHz LFSR random number generator(s). Is that the 32-bit Mersenne Twister RNG(s)?

 

Some of the documentation is confusing when read so it would be helpful to get that all sorted out.

[matthew180]

::rubbing hands together:: Exxxxxcellent...

I could not find anything so I'll post again.

 

I added the GROM clock register in response to some post that Willsy made back when I was working on the firmware (but I can't find the reference). He was going to make a circuit to let you control the GROM clock to modify the audio. I realized I could do that easily by just having a register control the GROM divide counter I was already implementing.

 

It works like this: I have the 100MHz main clock and a counter that counts the ticks. When the counter reaches a set value it resets and toggles a 1-bit register which is the GROM output clock.

 

Originally the GROM clock counter would count from 0 to 111, or 112 counts, then toggle the output. Remember this is counting the time between "toggles" of the output:

 

         ________
GROMCLK |        |________|
        0        111
                 0        111

.

Thus the total period of the counter is 224 counts of 10ns (the 100MHz main clock):

 

10ns * 224 = 2.24us period

1 / 2.24us = 446.428Hz or the 447KHz original GROM clock.

 

The GROM register (VR58) controls the count range of the GROM counter, which is counting for half the period (hence the term in the docs).

 

According to the datasheet the MAX freq of the 9901 is 500KHz, so I never allow the counter to count less than 111 (>6F). The register is 4-bits, but >0 to >6 are ignored and anything in that range will default to the normal >6F (111) count, i.e. you *set* >6F by writing anything below >7 to VR58.

 

The register is combined with >F, i.e. >7 becomes >7F, >D becomes >DF, etc. That leaves >7 to >F which will slow the clock and affect the audio output range (and GROM access time!) I did some basic calculations:

 

>7 (>7F) = 447.440KHz = 110Hz min freq

>D (>DF) = 223.720KHz = 55Hz min freq

>F (>FF) = 195.312KHz = 48Hz min freq

 

I think I limited the steps to 4-bits (instead of a full 8-bit register) because I didn't think there would be much use in having more than that.

Edited November 1, 2014 by matthew180

[matthew180]

Let me understand a few things....

 

The F18A is not only a FPGA based enhanced "TMS9918A-based" VDP which is in its own right somewhat of a modified TMS9900 IIRC...

The F18A is implemented using an FPGA, but an FPGA nor the F18A are a "modified TMS9900". You can implement a TMS9900 on an FPGA as a "soft core", which the F18A does happen to do to some extent.

 

running at 100 MHz.

Yes, the F18A is internally clocked at 100MHz.

 

I think I read somewhere that it also has a 100 MHz TMS9900 "co-processor". When reading some threads and all, I hear this so called "GPU".... is that referring to the VDP itself or the "100 MHz TMS9900 co-processor" (also on the same very FPGA).

After finishing the 9918A functionality I had almost 40% of the FPGA still available. Not wanting to let almost half of the FPGA's circuits go to waste, I decided to implement a TMS9900 core and wire it behind the VDP's normal 8-bit host-interface. Since this was a "CPU" inside a video processor, I decided to call it the "GPU". The GPU is not a 100% TMS9900, I left a few instructions out on purpose because they did not make sense in this context, and I added a few instructions that seemed desirable (hardware stack support for example). The "GPU" has direct high-speed access to the 16K VRAM, all VDP registers, an extra 2K of private "GPU only" RAM, and runs at the F18A's internal 100MHz clock. A typical 9900 instruction will execute on average of around 150ns to 250ns (around 4 to 6 million instructions per second) depending on the source and destination addressing.

 

I also read it has 32 Bit 100 MHz LFSR random number generator(s). Is that the 32-bit Mersenne Twister RNG(s)?

The V1.5 F18A has two 32-bit LFSRs as well as two 32-bit high-speed counters. The LFSRs are not a Mersenne Twister, just a 4-tap LFSR. However, in the upcoming V1.6 firmware I am removing all four components (the two LFSRs and the two counters) and replacing them with other features that are more desirable (second tile-layer and a blitter).

 

Some of the documentation is confusing when read so it would be helpful to get that all sorted out.

Probably. My fault really. The information in the forum is buried in long threads and you have to read the whole thread to know what is current (or read backwards). Documentation is a chicken-and-egg scenario though. Why write docs when there is a lack of interest in the F18A's enhanced features? However, you could also say there is a lack of interest because there is little official documentation. It is hard to justify the time, and I personally believe it is more of the former argument than the latter (and we *know* people are disinclined to read documentation at all, hence the existence of the venerable phrase "RTFM").

 

Right now the best course of action is to ask questions if you are interested (I try to be responsive), search the two main F18A threads, read the F18A register-use spreadsheet along with the 9918A datasheet, and check my website for possible posts with more details.

[Asmusr]

 

::rubbing hands together:: Exxxxxcellent...

 

I posted some sample code in post #223.

[Wildstar]

Thanks Matthew,

 

Ah, okay. I see the benefits there. The "GPU" when referred to is the F18A's internal "TMS 9900-based" processor. This would allow for some high speed GPU subroutines to be delivered. A blitter and second tile layer sounds interesting. From my AMIGA experience, the blitter is very handy. Finding some tight but effective ways to integrate some AMIGA like functionality is kind of cool. Since we would be hooking up to modern screens anyway and so in part being an upgrade makes the investment potentially desireable and not merely just a means to hooking it up to a VGA monitor.

 

As you probably have experienced, a part of the interest in the F18A hardware is that it provides some upgrade enhancements while also solving a need to sort of future-proof the TI-99/4A with easily readibly available displays. I have LCDs and CRTs with VGA connectors. The CRTs are desireable for light-pen operations which I believe would still work.

 

I'm just redug out the PEB. Just have to find where I have that stinking little cable that plugs into the big fat 5.25" floppy for use with the controller board and re-track down where I have the big ol' PEB controller board and "fire hose" cable. A lot of stuff in my archive.

 

The PEB alone is just about as heavy as a modern PC can without the plug in boards. The weight in just the metal.

 

I'm interested in the enhanced features and so forth. It is kind of important to figure out how to program for the enhanced features. This will be interesting as I'll be starting off with stock 16K RAM other than that provided for by the F18A and cassette recorder and possibly the Floppy drive once I find its cable.

[+OLD CS1]

 

I posted some sample code in post #223.

 

Really aggravates me that I searched for "clock" in this topic and your post did not come up. I will have a look; thank you. I am putting together a spreadsheet which will automatically calculate tone values given this register setting and the base of A (440Hz, 441Hz, etc.)

[+OLD CS1]

 

I posted some sample code in post #223.

 

VR58 is apparently not implemented in Classic99, so my observation of this phenomena will have to wait until Chicago as I have packed my TI in my luggage for shipping tomorrow. Bummer.

[Wildstar]

I'll probably be starting with using "Playground" strategy to getting ML/Assembly programming through on an unexpanded TI-99/4A.

[+OLD CS1]

Okay, I need a second set of eyes. I have put together an OpenOffice Calc (ODS) spreadsheet to calculate GROMCLK, lowest frequency, and hex tone values for each note across octaves, including offset based upon your tuning for middle-A (439Hz to 444Hz.) The problem is I cannot get the proper lowest frequency, and the frequency conversions do not come out correctly as the base frequency rate is calculating out incorrectly. For instance, with VR58 at >6F, GROMCLK is 447kHz after rounding up, but the base frequency is 111607.1429 rather than the 111860.8 per the E/A manual, giving 110Hz a value of >3F7 rather than >3F9 per E/A manual.

 

Would someone look at my formulas and help me out here?

 

Now the stuff that works:

 

On the Tone Table sheet, you should only adjust the VR58 value (>6F through >FF in >10 steps) from the drop-down. The Values sheet contains the settings limits, as well as some of the calculated values. You may also adjust the middle-A tuning to correct the note frequency and tone value tables accordingly.

 

Another feature is the note frequencies lower than Lowest Freq are greyed, as are tone values over >3FF. Note that there is an octave numbering discrepancy between musical octaves (I found called "scientific octaves") and TI's octaves: 440Hz middle-A in music is fourth octave (A4) while TI places it in the second octave (A2.)

 

 

 

EDIT: I have fixed the base frequency by adjusting the divisor from 4 to 3.99092... Now I am working on the lowest freq value. The GROMCLK value is not getting calculated properly, either. Whole darn thing is a mess!

 

Another EDIT: I have the hex Tone Values fixed by using ROUND() rather than INT() or ROUNDUP(). I just about have this worked out so I am going to pull the file until I get it tweaked.

[firepod]

Thanks to --- Ω --- and Cschneider, this will be the first mod I get after I get the PEB and Ti setup. I am pretty excited to get the TI hooked up to a 24" Led monitor going to rule!!!!

[Omega-TI]

Thanks to --- Ω --- and Cschneider, this will be the first mod I get after I get the PEB and Ti setup. I am pretty excited to get the TI hooked up to a 24" Led monitor going to rule!!!!

 

Good choice for a 1st mod!

IMHO, the F18A is without a doubt THE #1 modification for the TI.

I do have to warn you though, using the F18A is addictive as it multiplies TI enjoyment to manic levels.

[matthew180]

First, there are two sound chips, SN76489 and SN76494, and you have to make sure you are working with the correct one. The only difference between these two chips is that the SN76494 deletes a divide-by-8 circuit (see the datasheet) on the input clock to allow a lower input clock frequency of 500KHz vs the 3.5MHz to 4MHz typical input to the SN76489. Since the 99/4A uses the GROM clock to drive the sound chip, I believe the TMS9919 is just another name for the SN76494 (although I have never been able to find an actual TMS9919 datasheet).

 

The E/A manual has errors. On page 314 it states "... n/16, where n is the standard input clock frequency, 3.579545 MHz."

 

That is clearly a reference to the SN76489, which is not used in the 99/4A. The divide-by-16 is really a divide-by-2 in the SN76494 (9919). The later numbers do seem to be correct in the E/A manual and they get back on track to what the 99/4A will produce.

 

SN76489:
input clock -> [ 1/16 ] -> [ 1/n ] -> [ 1/2 ] -> [ attenuation ] -> [ mixer and amp ] -> audio out

SN76494 (9919):
input clock -> [ 1/2 ] -> [ 1/n ] -> [ 1/2 ] -> [ attenuation ] -> [ mixer and amp ] -> audio out

.

The divide-by-2 after the N-counter is simply due to the 10-bit N-counter being a *half-period* counter. Every time the N-counter reaches zero, it toggles the output (a flip-flop) which is why these sound chips produce square-waves.

 

So, you get some really basic formulas out of all of this. In the 99/4A, the input is the GROM clock which is technically 447,443.125Hz (see the 9918A datasheet for details).

 

The lowest frequency we can have from the sound chip is when the N-counter is maximum (10-bits == 2^10 - 1 == 1023). So let's establish some values:

 

CLK = 447,443.125

N = 0 .. 1023

 

If N = 1023, the output frequency would be:

 

447,443.125 / 2 / 1023 / 2 = 109.34582Hz

 

That is the lowest possible frequency. The highest frequency is when N = 2 (values of 1 or 0 produce a constant output):

 

447,443.125 / 2 / 2 / 2 = 55930.3906Hz

 

You can simplify this formula by doing the two divide-by-2 steps that are constant:

 

447,443.125 / 2 / 2 = 111,860.78125

 

This is that magic number you see in the E/A manual on page 315. Now you just divide 111,860.78125 by the frequency you want and that gives you the value to use for N (i.e. to stick in the 10-bit counter).

 

You can see in the E/A manual that the "code frequency" for 110Hz is: 111,860.78125 / 110 = 1,016.9161, which is rounded up to 1017. So put N = 1017 in the formula and you get:

 

447,443.125 / 2 / 1017 / 2 = 109.9909

 

You can also see that 110Hz is not the lowest frequency, 109.3458Hz is the lowest 99/4A frequency with an N-counter value of 1023.

 

With the F18A you can use VR58 to adjust the input GROM clock, so you modify the input value to your calculations and you get adjusted frequency values, for example:

 

VR58 = >F = 195.312KHz = 48Hz min freq

 

195,312 / 2 / 1023 / 2 = 47.7302Hz

 

The "magic number" for VR58 = >F becomes:

 

195,312 / 2 / 2 = 48,828

 

And 48,828 / 1023 = 47.7302Hz.

 

I hope this helps you get your spreadsheet fixed.

[Wildstar]

Actually, there are several numbers. There is the TMS9919. The models and production before the SN series labels were used. It was eventually called the SN94624. Variants were later came out in various SN764xx numbers.

 

 

http://en.wikipedia.org/wiki/Texas_Instruments_SN76489

 

Basically, the TI-99/4A had the TMS9919 and relabeled versions of the chip. The SN76489 added a divide by 8 to the clock input line while the 9919/SN94624 were limited to 500 KHz max input.

 

The ones labeled SN76494 were third party productions of the TMS9919/SN94624 in that they did not have the divide by 8 on the clock line and maybe deemed drop in replacements for the TMS9919....

 

It is the '89s (last two digits) were the ones with the divide by 8.

 

To add more fun, there were also the SN76496 and '96A. It just gets fun at times.

Edited October 30, 2014 by Wildstar

[+OLD CS1]

So it looks like I am missing the 10-bit counter value and trying to bypass it. I will integrate that into the spreadsheet. Tah donkeys!

[+OLD CS1]

Actually, I see what I am missing: the formula to convert your VR58 setting into a real clock frequency. If I plug in the proper clock frequencies manually, everything calculates out as expected. I cannot seem to get the same values from your first post. I will go back over it again and see if I am missing something.

[+OLD CS1]

Matt,

 

I have found my problem, and it is fully your fault. Referencing first post and second post, below.

 

In your first post you note a count of 111 (>6F,) doubled and tripped is 224, which gives a frequency of "446.428Hz or the 447KHz original GROM clock." This is what I get (446.4285714286) from my formula:

(1/((HEX2DEC(RIGHT('Tone Table'.K6;2))+1)*2))*100000

where cell K6 on 'Tone Table' holds the value >6F to >FF. Later in the post, however, you note that >7F gives that frequency:

>7 (>7F) = 447.440KHz = 110Hz min freq
>D (>D7) = 223.720KHz = 55Hz min freq
>F (>FF) = 195.312KHz = 48Hz min freq

 

I assume that was a type-o. Nonetheless, at >DF I get 223.2142857143, while >FF returns 195.3125 as you say.

Okay, now it gets more fun. In your second post:

 

CLK = 447,443.125
N = 0 .. 1023

If N = 1023, the output frequency would be:

447,443.125 / 2 / 1023 / 2 = 109.34582Hz

 

But I cannot derive 447.443125kHz from any prior values. Everything else I am doing is fine (at least if I feed manual values I get the correct targets.) Is there some reconciliation between the two posts that I have missed?

 

EDIT: I just noticed that the GROMCLK frequency you calculated with >6F and the frequency you gave as >7F are different: ~446kHz versus ~447kHz, so maybe >7F is not a type-o? I could assume some values given the settings.

[matthew180]

I did have a typo, the ">D7" should have been ">DF", and I corrected that in my previous post.

 

As for for the "real" GROM clock of 447,443.125Hz, you have to understand how that is generated by the real 9918A (did you read the datasheet?):

 

"The 10.7+ MHz master clock and its complement generate an internal six-phase 3.579545 MHz (+/- 10 Hz) clock to provide the video color signals and the color bust reference used in developing the composite video output signal. While the VDP signals are not exact equivalents to the standard NTSC color, the differences can easily be adjusted with the color and tint controls of the target color monitor."

 

Thus the 9918A requires a 10.738635MHz External Frequency (fEXT) to produce the NTSC colors, and from that the CPU clock and GROM clock outputs are derived by dividing that base 10.7MHz:

 

fEXT / 3 = 3.579545MHz CPU clock

fEXT / 24 = 447.443KHz GROM clock

 

In making the F18A there was no way I could exactly match the 10.7MHz clock, nor did I need to because my output is VGA which uses a 25.125MHz clock. However, I did need to produce a CPU and GROM clock that were *close enough*, as well as something close to the 25.125MHz for VGA. Technically the F18A internally generates a 100.227MHz (fCLK) clock that is divided like this:

 

fCLK / 4 = 25.056MHz VGA clock

fCLK / 28 = 3.579535MHz CPU clock

fCLK / 224 = 447.441KHz GROM clock

 

As you can see these are not exact, but they are close enough that the error does not affect the visual or audible output. Also, for the sake of simplicity, I typically drop the .227 part from the F18A's specs and just say it runs at 100MHz internally. So my previous calculations were probably made using 100MHz and not 100.227MHz, thus the discrepancy.

 

Your calculation for getting the GROM clock could be made simpler if you just divide 100,227,000 by twice the VF58 GROM period counter. Here is the complete table:

 

VF58 |half period            | full period                  | GROM clock out
---------------------------------------------------------------------------
>6F = 0..111 (112 ticks) * 2 = 224 ticks. 100,227,000 / 224 = 447,441.964
>7F = 0..127 (128 ticks) * 2 = 256 ticks. 100,227,000 / 256 = 391,511.718
>8F = 0..143 (144 ticks) * 2 = 288 ticks. 100,227,000 / 288 = 348,010.416
>9F = 0..159 (160 ticks) * 2 = 320 ticks. 100,227,000 / 320 = 313,209.375
>AF = 0..175 (176 ticks) * 2 = 352 ticks. 100,227,000 / 352 = 284,735.795
>BF = 0..191 (192 ticks) * 2 = 384 ticks. 100,227,000 / 384 = 261,007.812
>CF = 0..207 (208 ticks) * 2 = 416 ticks. 100,227,000 / 416 = 240,930.288
>DF = 0..223 (224 ticks) * 2 = 448 ticks. 100,227,000 / 448 = 223,720.982
>EF = 0..239 (240 ticks) * 2 = 480 ticks. 100,227,000 / 480 = 208,806.250
>FF = 0..255 (256 count) * 2 = 512 ticks. 100,227,000 / 512 = 195,755.859

.

 

From this we can make a table that shows the VR58 value to "magic number" values by doing the two divide-by-two operations which only leaves the sound chip's N-counter as the remaining variable:

 

VR58| GROM clock      | Magic Number
-----------------------------------
>6F = 447,441.964 / 4 = 111,860.491
>7F = 391,511.718 / 4 = 97,877.929
>8F = 348,010.416 / 4 = 87,002.604
>9F = 313,209.375 / 4 = 78,302.343
>AF = 284,735.795 / 4 = 71,183.948
>BF = 261,007.812 / 4 = 65,251.953
>CF = 240,930.288 / 4 = 60,232.572
>DF = 223,720.982 / 4 = 55,930.245
>EF = 208,806.250 / 4 = 52,201.562
>FF = 195,755.859 / 4 = 48,938.964

.

 

Finally we can use those magic numbers and do a highest and lowest possible frequency range by using 2 and 1023, respectively, for values of N:

 

VR58| magic num   | max f (N=2)| min f (N=1023)
----+-------------+------------+--------
>6F = 111,860.491 | 55,930.245 | 109.345
>7F = 97,877.929  | 48,938.964 | 95.677
>8F = 87,002.604  | 43,501.302 | 85.046
>9F = 78,302.343  | 39,151.171 | 76.541
>AF = 71,183.948  | 35,591.974 | 69.583
>BF = 65,251.953  | 32,625.976 | 63.784
>CF = 60,232.572  | 30,116.286 | 58.878
>DF = 55,930.245  | 27,965.122 | 54.672
>EF = 52,201.562  | 26,100.781 | 51.027
>FF = 48,938.964  | 24,469.482 | 47.838

.

 

You can derive any output frequency by dividing the magic number by any N-count of 2..1023. You can also start with a desired frequency, in a given range, and divide that into the magic number to get the necessary N-count value to produce that frequency.

 

For example, in the VR58 >6F range with a magic number of 111,860.491, to get a 440Hz output you would use an N-count of 254:

 

111,860.491 / 440 = 254.228

 

That same tone in the VR58 >FF range would be 111:

 

48,938.964 / 440 = 111.224

Edited November 2, 2014 by matthew180