F18A

[discomeats]

Wow, a whole metric crpload of things been happening, is there any way to make the BML visible over sprites and tiles, it'd be a lot more useful that way in that it could be used as an overlay, can it's size/position/colours be dynamically altered while the display is active?

 

Also, how much data can the 9900 core fling about, that certainly opens up the possibilities of some funky graphics.

 

btw, what sort of price are you expecting for completed boards now

[matthew180]

is there any way to make the BML visible over sprites and tiles, it'd be a lot more useful that way in that it could be used as an overlay,

 

Over tiles, yes. Over sprites, no. The BML has options to have a transparent color index (index 0) and tile priority, so it can be on top of, or behind, tiles. In the enhanced color modes, tiles can have priority over sprites (on a per "tile name" basis, i.e. any tile from 0 to 255 can have its priority set over sprites). With the BML it is all or nothing when it comes to priority over tiles.

 

can it's size/position/colours be dynamically altered while the display is active?

 

Yes. The BML has its own palette select which lets you use 4 colors from any of 16 "groups" of colors from the 64 palette registers. The palette registers are fully programmable at any time, so you can change the BML's colors via palette register updates or by changing the BML's palette select to point to a different set of 4 colors.

 

The size can also be changed at any time and will be seen during the next horizontal scan line.

 

Also, how much data can the 9900 core fling about, that certainly opens up the possibilities of some funky graphics.

 

The 9900-based GPU runs at the internal 100MHz clock rate, and being CISC it requires multiple clock cycles to perform its operations. Jump and branch instructions take about 5 clocks (50ns), instructions with two symbolic addresses take about 20 clocks (200ns). So the overall performance will vary depending on the actual code, but about 150ns per instruction is a pretty good average. The GPU has full direct access to the VRAM, and memory-to-memory (symbolic addressing for both src and dst) is about 5MB/sec.

 

btw, what sort of price are you expecting for completed boards now

 

I opened up pre-orders at the end of February and you can still get in on it. I'm very much behind getting them out when I had hoped, but testing is critical to me since I can't easily put out a firmware update once these are in the wild. I also found a hardware problem after having 250 boards made and assembling most of the pre-orders, but luckily I can fix it with just a part swap. Still, it takes time.

 

I'm getting close though, and might have all my testing wrapped up soon. Every time I run a test though, it proves I need to go through all the motions. A test I finished and ran just yesterday required a firmware change. It was a small change, but it was the difference between something working or not.

 

The price is currently $98. I want to get the cost down, and I'll be working on that once the pre-orders are done and shipped. I'm very grateful to those who pre-ordered! Because of their support and patience I am able to actually make the F18A available, since there was no way I could have fronted the money to have the initial boards made and buy the parts.

 

Once the pre-ordres are fulfilled, I'm *planning* on keeping maybe 10 F18As on hand to sell on my website. We'll see though, it all depends on the demand. If pre-orders are any indicator, it would appear that all 40 or so people who want one have ordered, and maybe that is the end of the demand.

[Tursi]

Pre-orders are never the full indicator in my experience. For some reason everyone tells you to open preorders, then sits and waits till everyone else has the product before deciding if they want one.

[discomeats]

I want one, things are just a tad tight at the moment, had a bunch of stuff decide to go "LOL, I AM BROKEN" at the same time, which is always fun.

 

Really, I want more than one but with my finances being $LOL atm kinda stuck for now.

 

But yeah, preorders are never really a guarantee of anything.

[matthew180]

The 32-bit counter and pseudo random number generator are testing and working. Below is a screen shot of forty 32-bit random numbers accessed by the 99/4A in 0x2CAD3 * 10^-9 second. :-) That is about 1.8ms to get access to all forty random numbers. The 0002 CAD3 value at the bottom is the 32-bit counter value I used to time getting the random numbers.

 

Note that the count does not include the time to display the numbers, only the instruction execution time necessary to seed the RNG, pump out ten numbers, seed again, pump out ten numbers, etc. up to four total seeds. The total time including display time (which included converting the numbers from binary to ASCII for display) was about 30ms.

 

This test was to verify the RNG sequence to make sure I wrote the HDL correctly. The F18A can generate each new random number in 10ns (one per F18A clock), but getting the result from the VDP to the host system takes a bit of time. The test code I wrote could also be made more efficient for use in a real program. Also, the value would generally need to be divided by the range of number desired, for example a random number between 1 and 100, so there would be further overhead.

 

However, it would be possible to use the GPU to make a random number in a given range, and that would only require the time to write to the VDP once (to trigger the GPU), and read the random number from VRAM, which would be one or two reads depending on the size of the random number, assuming the range does not go outside of 0 to 65535.

Edited June 20, 2012 by matthew180

[+OLD CS1]

I will "second" the pre-order versus demand notions. I want one, or two, but I am reduced to padding my Ramen Noodles with pocket fluff for the time being while I renegotiate on my house.

[idflyfish]

I'll be picking one up as soon as I can scrape together some cash.

[matthew180]

Testing is almost done! I'm on my short list. Recently I found a way (thanks to help from the people on the MSX.org forum) to access the F18A's enhanced registers from MSX BASIC. This makes writing tests *much* faster, and since the MSX does not use VRAM for anything (meaning it is left alone for the programmer to use as they want), I can even test features like the BML (bitmap layer).

 

Attached is a screen shot of what I call a "hat". It is the test program Stuart used to benchmark the computers he was building. MSX BASIC is no speed demon, and I didn't bother to clock this, but it was probably on the order of 10 minutes or so.

 

The other screen shot is a test with "everything" turned on. It is hard to see in the static photo, so here is a list of what is going on:

 

* The screen is pixel scrolling from right to left (yes from BASIC, very easy do to with the F18A)

 

* There are "fixed" tiles set that are not affected by scrolling

 

* There are borders (top, left, bottom, right) that are also limiting the area affected by scrolling

 

* ECM1 (enhanced color mode) is set, so any tile can be flipped x or y, made transparent, or have priority over sprites. The yellow tiles (A, C, E, etc.) have priority over sprites, are flipped on the x, and are set with a transparent background. The orange tiles are flipped on the y and have a transparent background.

 

* All 32 sprites are lined up along the screen, on top of the scrolling area and tiles with various attributes set, to create chaos (a worse case scenario) for the pixel priority determination logic.

 

* One sprite is moving from left to right while the screen appears to scroll right to left.

 

* The BML (bitmap layer) is enabled (x=35, y=50, w=100, h=100) and sitting on top of the whole mess. It was filled with random pixels, has priority over the tiles, and does not have transparency set. Sprites always have priority over the BML. The 100x100 BML is using about 2500 bytes of VRAM.

Edited June 29, 2012 by matthew180

[matthew180]

Testing is almost done and I promised the pre-order people I would start shipping today. I think I'm still on track for that goal, even if I can only manage a few out the door.

 

Here are a few images of the latest tests, which includes:

 

* The BML (bitmap layer) active in all screen modes

* Enhanced colors, tile attributes, and sprites in the text modes (40 and 80 column)

* VDP Register Reading

* Per scan line pixel and color palette updates

 

[rocky007]

great news !! im very impatient !

[+retroclouds]

Got a notification that my F18A (#45) is on its way to Germany :-)

woohoo!!!

[moulinaie]

I received my F18A....

 

Installed it....

 

and it WORKS !!!!

 

Thanks a lot to Matthew, an incredible image, very stable, clear, etc... Even without using the extra features, it really makes your TI99 usable without being tired looking at an old TV screen.

 

I didn't though about the sound problem..... Now I don't hear anything !!! I'll have to route the sound output to an external speaker.

 

Guillaume.

 

Some photos on my WEB page:

(english) http://gtello.pagesp...e.fr/ti99_e.htm

(français) http://gtello.pagesp...e.fr/ti99_f.htm

Edited July 23, 2012 by moulinaie

[matthew180]

I didn't though about the sound problem..... Now I don't hear anything !!! I'll have to route the sound output to an external speaker.

 

Yeah, sound is an issue for anyone who was using the 99/4A with the RF modulator and a T.V. If you were using a composite monitor though, with the A/V cable, then you just need to get a small external amplified speaker for the audio.

 

Another option is to get an audio jack mounted in the back of the case that picks up the audio from inside and routes it out. This is basically the same as using the A/V cable though, but allows you to use a standard (and readily available) audio patch cable for the sound instead of a DIN-to-Audio cable.

 

Making a modified A/V cable that has just the audio in it works too (which is what I'm doing). I think I saw somewhere (can't remember) a mod that used the RF modulator's cable to make an audio-only cable.

 

[moulinaie]

 

Making a modified A/V cable that has just the audio in it works too (which is what I'm doing).

 

That would be the best solution for me! Waiting for this, I made it in a dirt way, just look at my pages I've updated with the audio modif...!!

 

(english) http://gtello.pagesperso-orange.fr/ti99_e.htm

(français) http://gtello.pagesperso-orange.fr/ti99_f.htm

 

Guillaume.

[pcefan]

I got mine yesterday.

 

I'm very excited with this lovely hardware. Today i'll try to make some room in my garage and set my MSX (PASOPIA IQ HX-21) with buil-in F18A VDP.

 

Thanks Matthew.

[jstimson]

Got mine yesterday and managed to install it with little fuss. It looks fantastic on an LCD monitor.

 

One minor issue that I hope I did when i reassembled everything, I no longer get sound via the composite output. Tomorrow I'll take it apart and carefully inspect the connections on the DIN connector and other areas on the motherboard to see if I jostled anything. It was working just before I did the installation so I hope it's just a minor issue that I can find easily. Should mention this is an install for a silver TI 99/4A.

Edited July 27, 2012 by jstimson

[matthew180]

I'm glad to hear your F18A install went ok. As for the sound problem, you should be able to still use the 5-pin (or 6-pin if you have a EU 99/4A) DIN connector to pick up the audio. This is exactly what I do with my 99/4A systems running the F18A.

 

Make sure the metal shields are secure and aligned correctly when you reassemble. The 5-pin DIN is close to the edge and it is possible your sound is being grounded out.

 

The only other way the F18A could affect the sound would be if the GROMCLK output was not working, since it is generated by the VDP, and thus the F18A. The sound chip in the 99/4A uses the GROMCLK as its clock driver, however, your console would not work at all in that case since the GROMCLK is used by more than the sound chip.

Edited July 28, 2012 by matthew180

[jstimson]

I am using the DIN connector for audio, however after reassembling my TI the audio no longer worked. I have had my machine apart on several occasions and have stopped using the metal shielding a long time ago, so that's not an issue.

 

I'm going to take it apart again today and see if the solder joints on the DIN connector are solid, look for anything I might have jostled or damaged accidentally. I'm not blaming the F18A here, it's most likely my fat fingers that did something.

 

If nothing else, I do have a spare motherboard I can swap in and see how that works.

[+Vorticon]

Is the metal shielding needed for the PEB connector as a ground?

[jstimson]

Apparently not, I've run my TI for years (um, decades I guess) without the RF shield. I just found it more of a hassle to deal with when taking the console apart.

[jstimson]

Lack of sound - mystery solved!

 

I should have know better than to think it was something obvious. It was something totally unrelated to the actual upgrade.

 

I had my TI hooked up to composite inputs on a small colour TV. Everything works fine. Then I changed out the video chip for the F18A. Hooked up an LCD monitor for the video, but left the audio going into the TV just the way it was.

 

Turn things on and get no sound. Strange.

 

Turns out, if the TV does not get a video signal, it does not process the audio either. So confirmed sound works by hooking up to a small external speaker.

 

Now, everything works as expected and the picture is gorgeous.

[matthew180]

Until I get all the documentation done, I'm going to continue to post pieces of information here in response to emails or other F18A questions I receive.

 

These are the *new* instructions, and they use unused (that looks funny) 9900 opcodes:

 

* CALL 0C80 0000 1100 10Ts SSSS
* RET  0C00 0000 1100 0000 0000
* PUSH 0D00 0000 1101 00Ts SSSS
* POP  0F00 0000 1111 00Td DDDD
*
* SLC  0E00 0000 1110 00Ts SSSS

 

You can use these in any assembler by using DATA statements inline with the code. Examples with hard coded addressing (a pain I realize):

 

CSON   EQU  >03A0             * SPI chip select enable
CSOFF  EQU  >03C0             * SPI chip select disable
CALSYM EQU  >0CA0             * CALL Symbolic 0000 1100 1010 0000
RET    EQU  >0C00             * RET  0000 1100 0000 0000
PUSHR0 EQU  >0D00             * PUSH R0 0000 1101 0000 0000
POPR1  EQU  >0F01             * POP  R1 0000 1101 0000 0001
.
.
.
      LI   R15,>47FE         * Set the stack pointer to the bottom of the GRAM
.
.
.
      DATA CALSYM            * CALL @GETIDX
      DATA IDXNUM
.
.
. 
      DATA CSON              * SPI !CE (CKON opcode)
      DATA CSOFF             * SPI CE (CKOF opcode)
.
.
.
      DATA RET

 

The F18A uses R15 as the stack pointer, so it should be set up before any of the stack functions are used. The stack operations grow *down* in memory and the stack is always word operations (16-bit) on even addresses.

 

Modified instructions:

 

IDLE = IDLE    Forces the GPU state machine to the idle state, restart with a trigger from host
XOP  = PIX     The new dedicated pixel plotting instruction
CKON = SPI !CE Sets the chip enable line to the SPI Flash ROM low (enables the ROM)
CKOF = SPI CE  Sets the chip enable line to the SPI Flash ROM high (disables the ROM)
LDCR = SPI OUT Writes a byte (always a byte operation) to the SPI Flash ROM
STCR = SPI IN  Reads a byte (always a byte operation) from the SPI Flash ROM
RTWP = RTWP    Modified, does not use R13, only performs R14->PC, R15->status flags

 

XOP was chosen for PIX because it uses the workspace pointer similar to BLWP, and the GPU does not have a workspace pointer, and thus XOP would have been unimplemented anyway. Also, it provided useful enough addressing, i.e. general addressing for the source which allows the XY location bytes to be in a register or VRAM, and workspace register addressing for the destination (pixel command).

 

Unimplemented instructions:

 

SBO
SBZ
TB
BLWP
STWP
LWPI
LIMI
RSET
LREX

 

Since the F18A does not have a workspace pointer, interrupts, or a CRU, instructions related to those components were not implemented. Any unknown opcode will simply be ignored (NOP if you want to think of it like that), meaning it will not affect the GPU or cause it to go awry.

Edited July 30, 2012 by matthew180

[matthew180]

The GPU can plot a BML pixel, given an XY location, in a single instruction. It can also read a pixel, conditionally set a pixel based on the current pixel color, read and write a pixel at the same time, just calculate a pixel's VRAM address, or calculate a GM2 pixel's address!

 

Format: MAxxRWCE xxOOxxPP

M  - 1 = calculate the effective address for GM2 instead of the new bitmap layer
    0 = use the remainder of the bits for the new bitmap layer pixels
A  - 1 = retrieve the pixel's effective address instead of setting a pixel
    0 = read or set a pixel according to the other bits
R  - 1 = read current pixel into PP, only after possibly writing PP
    0 = do not read current pixel into PP
W  - 1 = do not write PP
    0 = write PP to current pixel
C  - 1 = compare OO with PP according to E, and write PP only if true
    0 = always write
E  - 1 = only write PP if current pixel is equal to OO
    0 = only write PP if current pixel is not equal to OO
OO   pixel to compare to existing pixel
PP   new pixel to write, and previous pixel when reading

 

I re-purposed the XOP instruction in the GPU as the PIX instruction, so any assembler supports it already. The source value is the XY location as two bytes, the X being the MSB. Since the XOP supports multiple address for the source parameter, you can use a register or memory location. XY values are 0 to 255.

 

The destination parameter is the PIX instruction as indicated above. If you use the M or A operations, the destination register will contain the address after the instruction has executed. If you use the R operation, the read pixel will be in PP (over writes the LSbits). You can read and write at the same time, in which case the PP bits are written first and then replaced with the original pixel bits.

 

Example:

      LI   R0,>2020     * xy=32,32
      LI   R1,>0001     * write a pixel of "01"
      XOP  R0,R1        * PIX R0,R1

- or -
      EVEN              * make sure XPIX is an even address
XPIX   BYTE 50
YPIX   BYTE 50
.
.
.
      LI   R1,>0801     * Read pixel XPIX,YPIX and write a "01" pixel
      XOP  @XPIX,R1

- or -
      LI   R1,>0302     * ONLY write a 2("10") pixel if the current pixel is 0("00")
      XOP  @XPIX,R1

- or -
      LI   R1,>0213     * ONLY write a 3("11") pixel if the current pixel is NOT 1("01")
      XOP  @XPIX,R1

- or -
      LI   R1,>8000     * Get the GM2 effective address of the pixel at XY location
      XOP  @XPIX,R1     * R1 now contains the VRAM address byte containing the pixel
                        * (XPIX AND >07) will isolate the bit in the specified byte

Edited July 30, 2012 by matthew180

[+retroclouds]

The PIX instruction seems to be very powerful. What I don't get is what you mean with writing a 2 ("10") pixel or a 3 ("11") pixel.

As we are talking bitmap layer I expected a 1 (pixel on) and 0 (pixel off) ?

Can you give some details on that? What about pixel colors?

 

I'm a bitmap rookie

[moulinaie]

The PIX instruction seems to be very powerful. What I don't get is what you mean with writing a 2 ("10") pixel or a 3 ("11") pixel.

As we are talking bitmap layer I expected a 1 (pixel on) and 0 (pixel off) ?

Can you give some details on that? What about pixel colors?

 

I'm a bitmap rookie

 

It's a bitmap with 2 bits per pixel (4 colors).

So color "2" is binary "10" and color "3" is binary "11".

 

Guillaume.