FM77AV - learning how to program it (english thread)

[malikto999]

Último mensaje de la página anterior:

:-(
The text is too small to be translated properly so I don't really know how it works. Seems that "1" value has an special meaning; but the image it's very blurry:

FM77AV_FD12_VSYNC.png

The above register is described in the Fujitsu manual.
However, even after reading it, I didn't understand the specific usage or effect.

For the time being, I will post the scanned image and translation of the relevant part of the manual tomorrow.

[jltursan]

Oh, indeed that helps, thanks jimbobaby!. Malikto999 already told us about the VSYNC bit in these old messages!

So, seems that this info is only available since FM77AV models and not present (confirmation needed!) in the FM-7 so maybe Pere didn't use it in his Shark game for the FM-7.

Now...

You can get display status and VSYNC status by referring to $FD12 of main CPU and $D430 of sub CPU.
$FD12 (bit1:display status / bit0:VSYNC status)
$D430 (bit7:display status / bit2:VSYNC status)

The meaning of each status is as follows.
Display status (0:Blinking period 1:Display period)
VSYNC status (0:non-vertical synchronization period 1:vertical synchronization period)

Seems indeed weird that two different registers related to VSYNC exists; but that offers more possibilities that one of them works . I think that both are complementary each other, bit 1 refers to the active displaying area and bit 0 to the vblank area.

Maybe using bit 1 Pere can detect the start of the vblank period checking for a 0 to appear...

[jimbobaby]

Maybe using bit 1 Pere can detect the start of the vblank period checking for a 0 to appear...

I don't think so, i think 1 should be while on vsync (so, can do whatever you want while 1).

I have already loaded Pere's last disk on mutsu, and can verify the flickering.

Thinking a little more, those are my assumptions:

1) Both ports ($FD12 and $D430), perhaps are the same data, but one port for each cpu? so, use the second one for vsync check only on the sub-cpu?. I don't have another explanation, there is only one monitor/CRT, and should be only one VSYNC.
2) From Pere's code, perhaps the problem is that doesn't have to check if it's inside the vsync period, but has to detect the transition from "not vsync" to "vsync" (so, the start of a vsync). If not, perhaps it's at the end of a vsync period and doesn't have enough time to do the painting before ending vsync, hence the random flicker.

EDIT: Yes, sorry jltursan, on a second read i understand what you said... bit 1 and 0 of FD12 should be opposite values and meaning, so, what you said is the same i said on point 2, you can check for bit 0 to transition from 0 to 1, or check for bit 1 to transition from 1 to 0, yes. If bit 1 is what we assume it is, of course

[malikto999]

A scan of the hardware manual.
I hope this information helps clarify how to use the VSYNC register.

FM77AV_HW_MANUAL_P180.jpg

(143.94 KiB) No descargado aún

8.6 Registers
This section describes various registers.

8.6.1 Display status register

The display status is located in bit 1 of $FD12 in main I/O space and bit 7 of $D430 in sub I/O space and has the following meanings.

0:Blanking period (horizontal and vertical)
1:Display period (horizontal and vertical)

The timing is as follows.

(1) 200 line mode

<Horizontal display period>
63.5Msec
23.8Msec | 39.7Msec
Horizontal blanking period | Horizontal display period
1 Horizontal period (1H)

<Vertical display period>
1/60sec
3.94msec | 12.70msec
Vertical blanking period | Vertical display period
1 Frame

FM77AV_HW_MANUAL_P181.jpg

(153.63 KiB) No descargado aún

(2) 400 line mode

<Horizontal display period>
41.04Msec
10.64Msec | 30.4Msec
Horizontal blanking period | Horizontal display period
1 Horizontal period (1H)

<Vertical display period>
18.06msec
1.64msec | 16.42msec
Vertical blanking period | Vertical display period
1 Frame

FM77AV_HW_MANUAL_P182.jpg

(162.35 KiB) No descargado aún

8.6.2 VSYNC status register

The VSYNC (vertical synchronization) status is located in bit 0 of $FD12 in the main I/O space, bit 2 of $D430 in the sub I/O space and port E35 of the key encoder and has the following meaning.

0:Not vertical sync period
1:Vertical sync period

The timing is as follows.

(1) 200 line mode

1/60sec
3.49msec | 12.70msec
Vertical display period
Vertical blanking period | Vertical display period
1.52msec | 1.91msec
VSYNC
0.51msec
0 | 1 | 0
Vertical sync period

(2) 400 line mode

18.06msec
1.64msec | 16.42msec
Vertical display period
Vertical blanking period | Vertical display period
0.34msec | 0.98msec
VSYNC
0.32msec
0 | 1 | 0
Vertical sync period

FM77AV_HW_MANUAL_P183.jpg

(218.69 KiB) No descargado aún

VSYNC status is used when:

Change palette register
Change display bank register
Switch display mode (computer, superimpose, video, digitize)

By looking at the VSYNC status you will see a beautifully modified screen from the beginning of one frame.

[jimbobaby]

Thank you, malikto999, very interesting!

So, from what i think of the info, perhaps bit 1 and 0 are not fully complementary all the time. As the graphs says, the blanking period is separated in 3 parts (front porch, vsync and back porch?), so i don't know what value has on bit 1 during all the vertical blanking period. Perhaps its the same during the full 3.49msec time.

Anyway, best to check for transition of vsync bit, to be sure.

[jimbobaby]

Well, with Pere instructions (on an old message) of how to make a development environment, i have tested the vsync code (i hope he doesn't mind ).

I have done some testing, and the idea of wait for vsync to end (if already there) and then wait for start again, doesn't seem to work, apparently.

Then, for tests,i replaced the keyboard routine for an automatic scroll, and draw less rectangles (3 to 1).

If i take out the vsync check, the "sprite" moves fast.
If i put the vsync back again, it's somewhat slower (good), and seems mostly "on sync" (there are some issues with the clearing old position, and some flicker, but less than before).
If the "sprite" (foreground) is 3 times wider (3 rectangles), then there is much flicker and almost no difference between vsync on or off.

(My windows computer is very old, and i'm using mutsu emulator, so ymmv)

My take on this, based on what i see, is that drawing code is slower than 2msec, still executing (sometimes at least) after vsync ends, or that some of the code is messing with video somehow.

Attached src&disk. Only changed the WaitKey routine behaviour, and the number of rectangles on FILLFG (3 to 1).

[jimbobaby]

Well, after a few more tests...

I have taken commented out HALT and SUBRST subroutines, and do it (only the HALT code) at the beginning of the program, just one time during execution, instead of two times (clearing and drawing) each frame.

With this change i get a smooth scroll, but with 3 rectangles "flickering" alternatively like the fake transparency shadows on games drawing on odd frames only. Weird.

But the vsync code seems working, at least.

[pser1]

Well, with Pere instructions (on an old message) of how to make a development environment, i have tested the vsync code (i hope he doesn't mind ).
I have done some testing, and the idea of wait for vsync to end (if already there) and then wait for start again, doesn't seem to work, apparently.
Then, for tests,i replaced the keyboard routine for an automatic scroll, and draw less rectangles (3 to 1).
If i take out the vsync check, the "sprite" moves fast.
If i put the vsync back again, it's somewhat slower (good), and seems mostly "on sync" (there are some issues with the clearing old position, and some flicker, but less than before).
If the "sprite" (foreground) is 3 times wider (3 rectangles), then there is much flicker and almost no difference between vsync on or off.
(My windows computer is very old, and i'm using mutsu emulator, so ymmv)
My take on this, based on what i see, is that drawing code is slower than 2msec, still executing (sometimes at least) after vsync ends, or that some of the code is messing with video somehow.
Attached src&disk. Only changed the WaitKey routine behaviour, and the number of rectangles on FILLFG (3 to 1).

Hi jimbobaby,
I have downloaded the files and will give it a try along this evening ... I hope to have time enough for that!
I decided to use three rectangles 3 bytes wide because Brody in the Tiburon game is defined with 8 bytes per row (56 rows), so it is a very
big sprite to move. We are dealing with a lof of bytes ...
In the black and white version of Tiburon/Shark I used the subsystem to draw on screen sending commands with data (yamauchi way)
and besides I have seen that there is some code related to an NMI control. I should re-read the source again because I have forgotten
almost everything about that version.
Maybe Malik could tell us the better way to move big images on the FM77AV, maybe with MMR or better using the SubSystem?
cheers
pere

[jltursan]

Without having a DMA or a 6309, a plain 6809 always can do this. It's a very nice reading.
Of course you can still use compiled sprites; but being huge, this would mean that a lot of RAM would be consumed.

You can find another great article about sprites and stack blasting here

[pser1]

Without having a DMA or a 6309, a plain 6809 always can do this. It's a very nice reading.
Of course you can still use compiled sprites; but being huge, this would mean that a lot of RAM would be consumed.

You can find another great article about sprites and stack blasting here

The stackblasting is very well known by the 6809 programmers. Glen is a wizard for the Coco3 and has some detailed tech explanations...
For the Tiburon for the FM7 using the subsystem was fast enough. No need for those tricks.
Now we need to know what did the programmers use when they designed games in dual 64 colour mode for the FM77AV
Once known we could test how it works with big sprites keeping into account that we will deal with B R and G Vram areas that are apart from one each other, so maybe we will need to remap Vram in the MMR registers ... or maybe we will have to find a better way to store coloured Brody sprite bytes in Ram to send the bytes to the Vram layer by layer ...
Just thinking out loud
Cheers
Pere

[malikto999]

In the black and white version of Tiburon/Shark I used the subsystem to draw on screen sending commands with data (yamauchi way)
and besides I have seen that there is some code related to an NMI control. I should re-read the source again because I have forgotten
almost everything about that version.
Maybe Malik could tell us the better way to move big images on the FM77AV, maybe with MMR or better using the SubSystem?

I've thought about it a bit, so here are some ideas for implementation.

Although direct access makes it much easier to communicate with subsystems, it also has its drawbacks.
FM77AV drops the CPU clock from 2MHz to 1.6MHz when MMR is enabled. (This has been improved in FM77AV20EX/40EX.)
Also, with direct access alone, the main CPU will be overloaded with processing, and the sub CPU will be wasted.

I think it's good to use both direct access and sub-CPU access.
Specifically, direct access is used when drawing the background all at once when switching between screens, and sub-CPU access is used to draw Chief Brody's pattern. (Disable MMR when not using direct access.)

The YAMAUCHI command can also be used for sub CPU access like FM-7, but FM77AV has an extended command, the IKEMOTO command, for executing code on the sub CPU side. (IKEMOTO is probably the developer's name, like YAMAUCHI, and was initially a hidden command.)
The IKEMOTO command can be used to secure an area for code placement and extend user commands for calling code.

Another thing to consider is reducing the pattern data size. The original Chief Brody is black and white, how many colors will you use when porting to FM77AV?
You don't have to use all 64 colors just because you're in 64-color dual screen mode. If only 8 colors (transparent color + 7 colors) are used, the number of bytes of pattern data can be halved. (Because the data for 6 plains becomes the data for 3 plains)

The 64-color 2-screen mode simulates background/foreground 2 screens by setting the analog palette. Since it is purely pseudo, depending on the palette settings, it can be applied to other than 2 screens with 64 colors. For example, an 8-color 4-screen mode is also possible.

If you have 8 colors each for foreground/background, VRAM will only use page0. (Assign B3, R3, G3 to the foreground and B2, R2, G2 to the background.)
All 48KB of page1 can be used as free memory. It's a good place to put Chief Brody's pattern data here.
(Set all palettes for page1 to black, so you don't see the pattern.)

This eliminates the need to transfer pattern data from the main CPU side to the sub CPU side each time a pattern is drawn, unlike the FM-7.
The main CPU simply specifies the pattern address of PAGE1 and the display address of PAGE0, and the subsequent processing (including things like VSYNC) is done by the sub CPU.

The architecture is little complex, but what do you think?
For the time being, I would like to introduce the IKEMOTO command and post a simple sample next time.

[jimbobaby]

The 64-color 2-screen mode simulates background/foreground 2 screens by setting the analog palette. Since it is purely pseudo, depending on the palette settings, it can be applied to other than 2 screens with 64 colors. For example, an 8-color 4-screen mode is also possible.

There are a lot of questions, but, if i understand correctly, there are no means for hw double buffering or changing the origin of the display buffer (i.e. like a VGA) to do hw scrolls, or something like that.

But it could be done playing tricks with the palette, showing and hiding back/front buffers.

In fact, not only you could do the 64 color dual screen mode, but could also (if i understant correctly) do a 256 color BG and 16 color FG (or a 1024 BG and 4 color FG, but this seems soo much unbalanced). Or do hw "transparencies" instead of BG+FG...all using palette tricks.

Another question. The sub-cpu has some kind of priviledged acces to VRAM? I mean, the both could work as a "dual core" system (both could do every kind of job if needed, graphics or program logic , i know they have different clock speeds-), or main cpu is faster with ram and sub-cpu faster with vram, for example? (or sub-cpu cannot access main ram or whatever).
Having direct access has some penalty for being activated? (other than wasting sub-cpu)

[jltursan]

If I've understood correctly, here's a summarized list of some facts:

- CPU runs at full speed (2Mhz) when working with its own main RAM.
- When MMR is enabled, the CPU can have direct access to VRAM but at a lower speed of 1.6Mhz.
- SubCPU is halted while direct access is enabled; so indeed, we're wasting a CPU.
- SubCPU always works at 2Mhz.
- SubCPU can only access to its own VRAM (true?).
- With the new IKEMOTO command, SubCPU now can execute arbitrary code (so indeed, a 6309 could enable its native mode?).
- The memory mapping is complex

[jimbobaby]

I have found something...

4096色モードではパレットの割り当てにより、重ね合わせ付きの64色2画面・16色3画面・8色4画面・単色12画面モードなどにすることができた。また、VRAMのオフセット指定による横8ドット/縦1ドットごとのハードウェアスクロール機能があり、オフセットは2画面別々に設定できた。このため、家庭用ゲーム機並みのゲーム画面も実現可能だった

(source https://www.owlapps.net/owlapps_apps/ar ... 92&lang=ja )

That translated seems to be something about this:

In the 4096-color mode, by assigning palettes, it was possible to make 2 screens of 64 colors with overlay, 3 screens of 16 colors, 4 screens of 8 colors, 12 monochrome screens, etc. In addition, there is a hardware scroll function for each 8 dots horizontally and 1 dot vertically by specifying the VRAM offset, and the offset can be set separately for 2 screens. For this reason, it was possible to realize game screens comparable to those of home-use game consoles.

For what its worth...

[jimbobaby]

- When MMR is enabled, the CPU can have direct access to VRAM but at a lower speed of 1.6Mhz.

- SubCPU always works at 2Mhz.

I think it's reversed... main CPU is always at 2Mhz, sub-cpu at 1.6. When stopping sub-cpu for direct (exclusive?) acces to vram, the speed is slowing down (for slower vram speeds or bus reasons, i don't know).

- With the new IKEMOTO command, SubCPU now can execute arbitrary code (so indeed, a 6309 could enable its native mode?).

I don't know if arbitrary, or "only for drawing". I can't get of my head the notion of larrabee (yes, totally unrelated in time and space, but...)

[jltursan]

I think it's reversed... main CPU is always at 2Mhz, sub-cpu at 1.6. When stopping sub-cpu for direct (exclusive?) acces to vram, the speed is slowing down (for slower vram speeds or bus reasons, i don't know).

Mmmm, I'm mostly sure that SubCPU speed is 2Mhz. Not sure if under some circumstances it'll be throttled down...

Soon mailkto999 will explain us the IKEMOTO command in detail; but reading the above posts seems that it allows to execute code, whatever code, that is placed in VRAM. That would be great!

[pser1]

I think it's reversed... main CPU is always at 2Mhz, sub-cpu at 1.6. When stopping sub-cpu for direct (exclusive?) acces to vram, the speed is slowing down (for slower vram speeds or bus reasons, i don't know).
Mmmm, I'm mostly sure that SubCPU speed is 2Mhz. Not sure if under some circumstances it'll be throttled down...
Soon mailkto999 will explain us the IKEMOTO command in detail; but reading the above posts seems that it allows to execute code, whatever code, that is placed in VRAM. That would be great!

I do agree!
SubCPU will always work @2MHz, and main CPU will stay @2MHz except when MMR is enabled, then it slows down to 1,6MHz
Let's wait for Malik's explanation about the use of IKEMOTO command ...
cheers!
pere