F18A

[matthew180]

I guess I'm not sure what you are thinking the F18A does. It is not an accelerator or anything like that, and it can't speed up a system, give it more RAM somehow, or enhance existing software. The F18A is a direct pin-compatible replacement for the 9918A/28/29 VDP, and produces analogue VGA output (i.e. HD15-pin) instead of a color-composite or component (in the case of the 9928/29) signal. The F18A can not do anything for the rest of the system beyond what the original VDP can do. The primary goal was to get VGA output for any system that uses the 9918A/28/29 VDP.

 

However, the F18A does make some enhancements to the VDP itself, i.e. all 32-sprites can be visible on the same horizontal line, the host system can not over-run the VDP by writing data too fast, there are programmable palettes with 4096 colors available, 9938 compatible 80-column mode, enhanced color for tiles and sprites, sprite and tile xy flip, and more. Whether or not any of that constitutes a "noticeable improvement" is up to the individual.

 

But, all that aside, the main feature is the VGA output. It is pixel-perfect, totally clear, no missing borders due to overscan, and works with any VGA monitor since 1987. I didn't think I was leading anyone to think otherwise?

[Willsy]

You can have 32 Sprites on a line if you want with the F18A. It is set with a jumper. However, *if* the *software* (game etc) is looking for 5 or more Sprites on a line then you will still see flicker, as the *game* will be moving the Sprites on and off the screen very fast (which makes them flicker) to try to get around the 4 on a line restriction. There is nothing the f18 can do about this: it can only obey the commands given to it by the host software.

[sometimes99er]

However, *if* the *software* (game etc) is looking for 5 or more Sprites on a line then you will still see flicker, as the *game* will be moving the Sprites on and off the screen very fast (which makes them flicker) to try to get around the 4 on a line restriction. There is nothing the f18 can do about this: it can only obey the commands given to it by the host software.

If that's how the software does is. I think most software would actually have a "rotate barrel" approach (all sprites in the list, just moved around), and hence the F18A would in fact show all sprites.

 

[matthew180]

I'm sure you two are both correct since different programmers probably came up with different ways to deal with the problem. In both cases, flicker on the F18A would depend on how long it takes the code to respond to the 5th sprite flag. If the code does not get everything updated before the next frame, it is possible that some sprites will flicker (on the F18A) since they might be off for a frame (or more.) I think Atari PacMan on the 99/4A is an example; if I recall correctly it still flickers on the F18A, but I'll have to test that again. I remember being surprised at that and wondered why it was still flickering.

 

It seems Yurkie assumes that the flicker is an artifact of the 9918A and was expecting the F18A to fix this problem. That is not the case. The flicker is due to software tricks trying to get around the 4-sprite limit of the original VDP.

 

I'm guessing that for most games the flicker will go away, but there is no guarantee and nothing I can do in the F18A to ensure it sprites won't flicker. Games with the best chance of having the sprite problems fixed are those that simply ignored the 5th sprite problem and let the sprite disappear. Next will be games that did some sort of rotation, and managed to do it before the next frame.

[+Yurkie]

Yes, I got it in my head that your module was going to allow all 32 sprites lined up with no flicker.

 

Very disappointing for me, but you still have an awesome product.

[sometimes99er]

Yes, I got it in my head that your module was going to allow all 32 sprites lined up with no flicker.

It will, see post #52.

 

[+OLD CS1]

However, *if* the *software* (game etc) is looking for 5 or more Sprites on a line then you will still see flicker, as the *game* will be moving the Sprites on and off the screen very fast (which makes them flicker) to try to get around the 4 on a line restriction. There is nothing the f18 can do about this: it can only obey the commands given to it by the host software.

If that's how the software does is. I think most software would actually have a "rotate barrel" approach (all sprites in the list, just moved around), and hence the F18A would in fact show all sprites.

 

 

What does "Midnite Mason" do?

[+OLD CS1]

However, *if* the *software* (game etc) is looking for 5 or more Sprites on a line then you will still see flicker, as the *game* will be moving the Sprites on and off the screen very fast (which makes them flicker) to try to get around the 4 on a line restriction. There is nothing the f18 can do about this: it can only obey the commands given to it by the host software.

If that's how the software does is. I think most software would actually have a "rotate barrel" approach (all sprites in the list, just moved around), and hence the F18A would in fact show all sprites.

 

 

What does "Midnite Mason" do?

[matthew180]

Yes, I got it in my head that your module was going to allow all 32 sprites lined up with no flicker.

 

It *will* display all 32 sprites on a single horizontal line without flicker. There is one exception that is totally out of my control, and that condition is where the code running on the host system does something (who knows "what" exactly, maybe trying to rotate sprites to prevent flicker on the original VDP) to prevent a sprite from being displayed for at least 1 frame. In that case, the sprite would flicker, but it has nothing to do with the F18A, since the code told the sprite to go away.

 

I don't know where we are failing to communicate, but I can't make it any clearer. Anyone else want to help?

[+retroclouds]

True, flicker has nothing to do with the 9918/9928VDP or F18A for that matter.

 

Flicker is introduced by the game programmer, trying to come up with an algorithm/subroutine for avoiding 5th sprite (or more) on the line being hidden when running with a 9918/9928VDP.

Depending how good/bad the "flicker" subroutine was programmed, you'll see less or more flicker.

[+Yurkie]

Yes, I got it in my head that your module was going to allow all 32 sprites lined up with no flicker.

 

It *will* display all 32 sprites on a single horizontal line without flicker. There is one exception that is totally out of my control, and that condition is where the code running on the host system does something (who knows "what" exactly, maybe trying to rotate sprites to prevent flicker on the original VDP) to prevent a sprite from being displayed for at least 1 frame. In that case, the sprite would flicker, but it has nothing to do with the F18A, since the code told the sprite to go away.

 

I don't know where we are failing to communicate, but I can't make it any clearer. Anyone else want to help?

 

 

Are you saying since the 9918 could only handle 4 sprites that cv games where more than 4 are in a row , flicker was programmed into the game and the FPGA is just reading the program?

Edited September 2, 2011 by Yurkie

[+OLD CS1]

Addendum to my question above. The capture did not get the real-time flicker very well, but you should be able to clearly see that "Midnite Mason" makes the ghost sprites turn off, apparently in sequence, to give both an apparition appearance and to avoid the five-on-a-line issue when the player is on the screen.

 

[+5-11under]

Yes, I got it in my head that your module was going to allow all 32 sprites lined up with no flicker.

 

It *will* display all 32 sprites on a single horizontal line without flicker. There is one exception that is totally out of my control, and that condition is where the code running on the host system does something (who knows "what" exactly, maybe trying to rotate sprites to prevent flicker on the original VDP) to prevent a sprite from being displayed for at least 1 frame. In that case, the sprite would flicker, but it has nothing to do with the F18A, since the code told the sprite to go away.

 

I don't know where we are failing to communicate, but I can't make it any clearer. Anyone else want to help?

 

 

Are you saying since the 9918 could only handle 4 sprites that cv games where more than 4 are in a row , flicker was programmed into the game and the FPGA is just reading the program?

Pretty much, yes. It all depends on how the game is programmed, and there are different methods available.

 

For example, on the F18A with 32 sprite mode selected, if there are 5 sprites used in a game, and they all end up on the same scan line, the programmer can:

a. Ignore sprite management: 5th sprite will be seen.

b. Rotate the order of the 5 sprites every cycle: 5th sprite will be seen.

c. Move one of the 5 sprites off the screen for one cycle: only 4 sprites will be seen.

I'm sure there's other methods available, too, but I've at least shown cases where the sprites are managed, but still may or may not flicker.

 

Bottom line: you'll have to try each game using both methods to see which one works best, if there is a difference (or gain information from the programmer or possibly through viewing the game).

Edited September 2, 2011 by 5-11under

[matthew180]

Are you saying since the 9918 could only handle 4 sprites that cv games where more than 4 are in a row , flicker was programmed into the game and the FPGA is just reading the program?

 

First, let's be clear about the FPGA. It does not *read* any code or program running on the host computer (99/4A, CV, MSX, or whatever.) The FPGA is a massive logic chip that I have used to recreate the functionality of the original 9918A/28/29 VDP. To the host computer, it looks, acts, smells, tastes, etc. just like the original VDP.

 

To understand the flicker, you have to understand how the 9918A does video, which I assumed was understood here. If not, this might clear it up:

 

A TV usually displays a "frame" 30 times per second (talking about NTSC here, PAL puts out a "frame" 25 times per second), and a "frame" is made up of an even-field and an odd-field, i.e. a TV picture is interlaced. So, you get 30 even fields per second and 30 odd fields per second, which makes up the TV picture. For NTSC, frames happen at 30HZ, fields happen at 60HZ.

 

The 9918A outputs an even "field" only, at 60 times per second, i.e. at 60HZ. What this does is forces the TV to always display an even field for both the even AND odd fields. This cuts the resolution of the overall picture, but it makes a very stable picture.

 

Now, if you were to display a graphic (like a sprite) on the screen, it would look very stable. However, if you write a program to turn that same graphic off every other frame, the graphic will flicker since it is only being displayed at a rate of 30 fields per second. If you do something like that, the VDP can not "fix" the flicker because there is actually nothing wrong, since your program *told* the VDP to turn off the graphic every other frame. The VDP has no idea why the human programmer is turning a graphic on and off every other frame, it just does what it is told. The VDP is not "intelligent" or self-aware.

 

The 9918A puts out an interrupt signal for every field (60 times per second) around the time of the vertical refresh, which a lot of games use for timing and to do screen updates. On the CV, the VDP interrupt is directly tied to the Z80 NMI and the interrupt can not be ignored. At this time (when the interrupt is received) the host CPU can also read the VDP status register which, among other information, includes the 5th sprite number which is set any time there are more than 4 sprites on a horizontal line.

 

Any time there were 5 or more sprites on a line, the host CPU does not get that information until *after* the field was displayed, so the 5th or more sprites on a line were already not displayed (or partially not displayed; only the overlapping horizontal lines of the 5th or more sprites are not displayed.) At this point, *some* software detects this and tries to rearrange the sprite priorities so that the sprites that were not displayed will be on the next field. So, this is what produces the flicker. The VDP does not display the 5th or more sprites, and the software rearranges things so they do show up on the next field. Of course sprites that did show up on the previous field are now the 5th (or greater) sprite, so they are dropped on the next field. So all the sprites flicker.

 

The flicker problem can also be worse if the code that is doing the sprite rearranging does not finish before the next field starts. In that case you might have a sprite missing for two fields. Also, some programs may try to manage more than 8 sprites, which means some sprites will be off for more than one field.

 

The VDP has nothing to do with all this sprite "management" and only does what it is told to do. In "most cases", the F18A will fix the problems since it can always draw all the sprites. Programs that simply accepted the loss of the 5th or more sprites, and didn't try to do any rotation, will benefit the most since the F18A will simply be drawing all the sprites. Even code that does do the sprite management, since all the sprites will be displayed, should not affect the sprites and thus no flicker. But, it is still possible that the sprite management code turns off some sprites during the management, and in those cases, there is nothing the F18A (or anything else in the world) can do to fix the problem; the code *TOLD* the sprite to shut off... The only thing that could fix that would be to change the code.

 

So:

 

1. Can the F18A display all 32 sprites on the same horizontal line at the same time, every field, without flicker? YES

 

2. Will sprite "flicker" in games be fixed? USUALLY, but it depends on how the game is coded on the host computer

 

3. Can the F18A prevent all sprite flicker no matter what the host computer is telling it to do? No. The F18A will do what it is told to do. If that means shutting off a sprite every other field, then it will do so and the sprite will flicker, as it *should* (because it was told to flicker.)

Edited September 2, 2011 by matthew180

[Tursi]

For what it's worth, Mario Bros on the ColecoVision uses the 'rotation' approach to it's flicker. Because all sprites are registered for every frame, Mario Bros does not flicker with the F18A (it's nice and solid).

 

But there are some programmers on some titles who, instead of rotating the sprite priorities, actually do not draw some sprites on the screen for some frames. No replacement video chip can do much about that.

[matthew180]

Current status:

 

*Original 9918A functionality: 100% (based on the features I'm going to reproduce, which is everything *except* the composite output, external video in / overlay, and 4K addressing / support.)

 

* 9938 80-column mode: 100%

* Horizontal and vertical pixel-level scrolling of 1 screen: 100%

* Programmable palette registers, 64 of them, 12-bit color: 100%

* VRAM increment by 1 or 32: 100%

 

In the scroll screen shots what you can't see is how smooth the pixel scroll is. I tried to take and action shot... Also, the colored blocks in the middle are pulsing through the 16-levels of each red, green, and blue color. These tests are running on a stock 99/4A. Also shown are the SpectraVideo-328 and MSX1 Toshiba HX-10 with the F18A. The nice example on the SV328 was done in the ROM BASIC!

[+acadiel]

*drool*

[+Ksarul]

Excellent! This is a great progress report!

[matthew180]

I forgot to include 30 row mode in the update. It is working 100% too.

[kl99]

Regarding the more than 4 sprites in a line problematic.

 

If I understand this topic technically correct, there are four types of programs:

 

• 
   
  1. program simply ignores that the 5th sprite is not shown
  2. program reads the 5th sprite status flag and the program reacts in some way
  3. program knows by other variables (coordinate variables) that there are now more than 4 sprites in a line and react in some way
  4. program always rotates the sprites even if there are less than 5 sprites in a line
  

For now the F18A handles the first case perfect by simply setting the jumpers on the board accordingly

Case 2, 3 and 4 however can still cause flickering on F18A machines.

 

If the jumper settings would allow a mode that the F18A doesn't set the 5th sprite flag, even if more than 4 sprites are in a line, case 2 could be handled quite perfectly. The program from case 2 only reacts to the 5th sprite flag which will never be set in such a mode. So the flickering handling of the program is never triggered.

 

There is no way to handle case 3 and 4 of course - without reprogramming the program itsself. I doubt there are too many assembler programs which doesn't use the 5th sprite status flag in their sprite handling mechanism.

[Willsy]

Actually, that's a pretty neat idea!

[matthew180]

If the jumper settings would allow a mode that the F18A doesn't set the 5th sprite flag, even if more than 4 sprites are in a line, case 2 could be handled quite perfectly. The program from case 2 only reacts to the 5th sprite flag which will never be set in such a mode. So the flickering handling of the program is never triggered.

 

I thought about that, quite a bit actually. However, it is very hard to anticipate the side affects. Some software might need that flag to trigger some other action, not just sprite rotation. It is hard to tell until you set it up and then test all known software...

 

The problem really has 4 states though, so it is hard to set it via a single jumper:

 

1. Sprite flag with greater than 4 sprites (original)

2. Sprite flag with greater than 8 sprites (9938)

3. No sprite flag (possible F18A option)

4. Sprite flag only when sprite is greater than sprite_max (possible F18A option)

 

The F18A has a new sprite_max register than can be changed via code. At power-on reset (PoR) the F18A looks at a jumper to determine the initial value of the sprite_max register, either 4 or 31 (all sprites) depending. After that, a program can change the register to anything between 0 and 31, where 0 will disable sprites entirely. Also, the default value (as set by the jumper) is *only* considered with a PoR, which means the sprite_max setting will survive soft resets. Thus, an F18A could be set to 4-sprite max (via the jumper) for compatibility, and a utility program could be used to change the sprite_max for use in any other legacy programs as long as the power is not turned off. Edit: actually, now that I think about it, I believe plugging in most cartridges will cause a "hard" PoR, so the "soft settings" would be blown away.

 

Anyway, while I was implementing the sprite_max circuit, I considered making the 5th-sprite flag set only when the sprites on a line was greater than the sprite_max setting. So, for example, if you have sprite_max set to 10, then only when 11 or more sprites were on a line would the flag be set. If sprite_max was 4, then the original functionality would result.

 

I kicked that idea around a *LOT*. Currently, the flag still gets set when there are 5 or more sprites on a line, regardless of the sprite_max setting. That could certainly change though, and I welcome any comments / feedback on this. The sprite limit has always caused compatibility controversy and is the primary reason I added the jumper block on the board. Currently only two of the jumpers are doing any thing, so I could dedicate another to sprites, but we don't even know if this is an issue yet.

Edited September 12, 2011 by matthew180

[Tursi]

Regarding the more than 4 sprites in a line problematic.

...

For now the F18A handles the first case perfect by simply setting the jumpers on the board accordingly

Case 2, 3 and 4 however can still cause flickering on F18A machines.

 

This is actually not true, because whether it flickers depends on how the software reacts to the sprite limit.

 

Most programs that flicker, as far as I have seen, rotate the sprite priorities but still display every sprite. Consider the case of a program with 8 sprites, and assume they are all on one line.

 

Frame one displays like this:

 

1 2 3 4 5 6 7 8

 

and frame two (logically) like this:

 

5 6 7 8 1 2 3 4

 

They way it does this is by keeping a CPU copy of the sprite table, and copying it each frame into the real sprite table. So anyway, this will flicker by swapping which of the sprites are higher priority.

 

Because all the sprites are displayed in all cases, the flicker will not occur when the F18A is displaying all 32 sprites on a line.

 

The only case it will still flicker is if the program does not display one or more of the sprites. To use the above example, frame one like this:

 

1 2 3 4

 

and frame two like this:

 

        5 6 7 8

 

Since only four sprites are actually displayed per frame, there's no way for the hardware to correct it.

 

Either of these approaches can be used with cases 2 3 and 4, since those only determine when to act, and not what to do about it.

 

I think in practice you'll find that not much software uses the 5th sprite on a line flag to trigger the flicker code.

[matthew180]

I think in practice you'll find that not much software uses the 5th sprite on a line flag to trigger the flicker code.

 

Based on that comment, I changed the 5th sprite flag to be the "sprite max" flag, i.e. is gets set only when more sprites would appear on a line than the sprite max setting, which I always have set to 32 via the jumper.

 

I tested with the Atari's PacMan for the 99/4A. This is a very excellent looking port of the original game, but it is *slow* moving. They actually do the ghost's eyes via tile animation and put the ghost sprite on top. It looks really nice, but even on the F18A the ghosts flicker a little. It is not really that bad and very easy ignore, but this is an example where the F18A (or any hardware, existing or magical) can't help. The flicker is due to the programming, and it is hard to be sure why without having the source code to examine.

 

It is not a consistent flicker either, which really makes me wonder what is going on? Mainly because when all four ghosts and PacMan get on the same line, with the 9918A the brown ghost drops out, but with the F18A the brown ghost remains visible. So, with the ghost dropping on the real 9918A, their sprite rotation is either not effective or there is really no sprite rotation going on; and if that is the case, why do the ghosts flicker at all?

 

Anyway, you probably have to see it to really get a sense of what it looks like, but I thought it was a good example of how programming, and not hardware, ultimately determines what happens on the screen.

 

Something I just thought of... The slight flicker in PacMan may be due to the ghosts and PacMan sharing the same "name", i.e. all the sprites are set to point to the same 4 tiles in VRAM. So they may be updating the patterns every other frame or something?! I don't know why they would do that just to save 64-bytes of VRAM, but what makes me think they do that is this:

 

During some sprite testing I had the F18A draw all the sprites all the time, regardless of screen mode or the >D0 byte that you can use to disable further sprite processing. They when I played PacMan and was caught by a ghost, *all* the ghost sprites, as well as PacMan, went through the dieing sequence. It kind of freaked me out at first, but when you play the game with normal sprite functionality, you will notice that when PacMan dies, the ghosts are disabled, i.e. not drawn. What that shows is, at least during the dieing sequence, all the sprites are pointing to the same pattern memory, i.e. all the sprites have the same "name".

 

So, if the ghost and PacMan sprites are sharing the same pattern memory, that would explain the flicker and why the F18A won't help. The ghosts and PacMan would be drawn every other frame (30 FPS) when the pattern memory contains the ghost or PacMan data. It might be an interesting adventure to use Classic99 and step through the PacMan code to see what is going on, but I'll save that for another day.

[+OLD CS1]

My first instinct was that Atari was turning off the sprite before moving it, and the flickering was just an artifact of doing so. Then during the dying sequence, they just pointed the ghosts to a "0" tile location (Pac-Man's tile) and turned them all off except Pac-Man.