FM77AV - learning how to program it (english thread)

[malikto999]

Último mensaje de la página anterior:

The Basic3.3 seems to have changed something in the configuration of the XM7 because once run the 64 colours example
there is no way to start the old .d77 I had made with prior examples.
Now calling "xm7 diskname" results in an endless beep that can only be stopped pressing Alt+F12
Then I need to change "DOS Mode" to "BASIC Mode" and then loading the 'old' .d77 requires pressing F12 for the
program to start (using the STARTUP basic program)

I think it's a problem that doesn't occur on the real machine, so I think the cause is on the XM7 side, but I tried various things, but I couldn't reproduce your phenomenon.
Does your report mean that XM7 switches from BASIC mode to DOS mode arbitrarily when you boot FBASIC3.3?

I once encountered an issue where some XM7 settings were not saved.
I remember that this was caused by the version of XM7, where the program was placed (e.g. directly under program files), and whether or not you had windows administrator privileges at the time of execution.

I'm sorry, but that's all I can think of right now.

Ps By the way, is there an FBASIC33.ROM file to add to the XM7 folder?

FBASIC V3.3 has only disk BASIC, so there is no file like FBASIC33.ROM for emulator.
All the BASIC code body of V3.3 is stored in the floppy disk.

[pser1]

@malikto999
Talking about the PAL64S.ASM ...
There is a subroutine called SETPAL that prepares the values of BRG for each of the 4096 colour codes and then
sends these values to FD30-34.
I asume that this part is mandatory, and doing so the Basic program can later use the two tables of just 64 entries
referring to any colour number from 0 to 4096 as index
The question is ... The 4096 mode comes out from using 16 values per BRG, so 16x16x16 = 4096
But when talking about the dual 64 colours mode, each page has data correspondig only to two bits of colour
that makes sense to me because 4x4x4 = 64
The problem is how come this change in definition works for the dual mode?
Is it possible that the values sent to FD32-34 are always reduced to values 0,5,10,15 so that only four levels
of each colour are used?
cheers!
pere

[pser1]

@malikto999
Hello,
I modified the PAL64S source code so that the calculated values (BRG) for each colour code
are saved from $2000 on. Then I saved these bytes to a binary file and have extracted it from
the .d77
Then I entered the PAL64 program that comes in Oh!FM 1986,January in page 37 and then I added
regU pointing to the end of the program where I had reserved 4096x3 bytes
Once executed the program, I saved these bytes to a binary file and extracted it too.

When comparing the contents of these two files, we can see that the output created by the
Oh!FM article has values $00,$05,$0A,$0F only, so it is using 4 values for each component.
It is not clear how to put values higher than 3 in dual 64 colour mode on a single plane where
only two bits are devoted to each colour.
On the other hand, looking at the output created by the PAL64S source code, we can find a lot
of values that are out of this list and most strange, there are a lot of entries with zero value
for the three components, from $0B30 to $3100.

When I execute the assembly program from Oh!FM, it ends (with FBASIC33 disk) and exits
changing the mode to something that reminds me an interleaved mode with a black line inserted
after each data line for the text ... see image.

How could I switch to the dual 64 colours mode and then go back to normal 40x25 text mode?

I attach here the source code copied from the magazine so that you could see the use of
$FD12 for SubMode changes and $FD37 for MulPag (names given in the magazine)

In the zip you will find the two output files with the BRG values for the 4096 possible codes
and the virtual files used (.d77)

cheers!
pere

Screenshot after PAL64 from OHFM8601.jpg (15.61 KiB) Visto 684 veces

Dual 64 colours mode.zip

(107.76 KiB) Descargado 8 veces

[attachment=1]

[pser1]

Hello,
concerning the last screenshot I uploaded here, I have found out that this strange behaviour
appears when you POKE &HFD12,&H4x and can be reversed with POKE&HFD12,&H00
So the program from the magazine Oh!FM 1986,January page 37 that ends with
lda #$40
sta SUBMOD ; $FD12
should be modified to
clra
sta SUBMOD ; $FD12

Anyway, the PAL64 demo was done from BASIC calling the function LINE using the colours saved
in the two tables each 64 entries ...

How could we set that double 64 colours mode from assembler programs?
How can we tell the computer that a single plane has to work with 2bits for each colour component?

cheers!
pere

[malikto999]

@malikto999
Talking about the PAL64S.ASM ...
There is a subroutine called SETPAL that prepares the values of BRG for each of the 4096 colour codes and then
sends these values to FD30-34.
I asume that this part is mandatory, and doing so the Basic program can later use the two tables of just 64 entries
referring to any colour number from 0 to 4096 as index
The question is ... The 4096 mode comes out from using 16 values per BRG, so 16x16x16 = 4096
But when talking about the dual 64 colours mode, each page has data correspondig only to two bits of colour
that makes sense to me because 4x4x4 = 64
The problem is how come this change in definition works for the dual mode?
Is it possible that the values sent to FD32-34 are always reduced to values 0,5,10,15 so that only four levels
of each colour are used?
cheers!
pere

In the 64-color dual screen mode, Page0 and Page1 each have a palette of 64 colors, and you can assign 4096 colors to this palette in any way.
In other words, you can choose any 64 colors out of 4096 colors and assign them to the palettes of Page0 and Page1 respectively. Unassigned colors cannot be displayed.
64 colors can be assigned to the palettes of Page0 and Page1 respectively. You don't have to choose the same color for Page0 and Page1.

* More precisely, you cannot assign a color to the 00th palette of Page0 (foreground) because it will be the transparent color of Page1 (background).

The color level values(0-15) set in $FD32-$FD34 are never reduced. Colors are displayed as specified by the color levels in the palette. The number of VRAM plains in the page is irrelevant to the color level specified in the palette.

I would like to explain the idea of?palette setting in another comment.

[malikto999]

@malikto999
When comparing the contents of these two files, we can see that the output created by the
Oh!FM article has values $00,$05,$0A,$0F only, so it is using 4 values for each component.
It is not clear how to put values higher than 3 in dual 64 colour mode on a single plane where
only two bits are devoted to each colour.
On the other hand, looking at the output created by the PAL64S source code, we can find a lot
of values that are out of this list and most strange, there are a lot of entries with zero value
for the three components, from $0B30 to $3100.

I would like to write more about the analog palette settings in another comment, but I will comment on the above.

Oh!FM's program decimates each level of BRG and specifies only $00, $05, $0A, and $0F in order to evenly assign 4096 colors to 64 colors. On the other hand, my sample specifies the palette based on the BRG values ​​set in advance in the table. Therefore, it is natural that the contents of the palette set by both programs are different.

Also, the reason why there are many 0s in my sample is very simple. That's because I cut corners and set RGB from 9 to 63 in the foreground palette (PLTPG0) to 0 (that is, black).

Once again, in 64-color dual screen mode, the color levels specified in $FD32-$FD34 are never reduced. In the standard, 4096 colors can be used, but in the 64-color dual screen mode, only 64 colors can be used for the each foreground (Page0) and background (Page1). The palette colors to be assigned to the 64 colors are specified from among 4096 colors. (i.e. specify $FD32-$FD34 in 0-15 level.)

[malikto999]

A detailed explanation is likely to come after tomorrow, so I will briefly supplement the palette settings.
Also, please read my previous comment first if you can.

Recall the formula below.
palette code = 2048*G3 + 1024*G2 + 512*G1 + 256*G0 + 128*R3 + 64*R2 + 32*R1 + 16*R0 + 8*B3 + 4*B2 + 2*B1 + B0

The palette for background (Page0) is set only when all bits of foreground (B2, B3, R2, R3, G2, G3) are 0.
There are 64 combinations of background bits (B0, B1, R0, R1, G0, G1) from 0 to 63.
That is, I assign colors to 64 palettes.

On the other hand, the palette for the foreground (Page1) writes the same regardless of the state of the background (B0, B1, R0, R1, G0, G1) bits.
Since there are 64 combinations of background bits, the same BRG is set in 64 palettes for each one color of the foreground.
There are 64 combinations of foreground bits (B3, B2, R3, R2, G3, G2) from 0 to 63, just like the background. However, if all bits are 0, it becomes a transparent color, so there are actually 63 ways.
In total, 64 background + 63*64 foreground = 4096, matching the total number of palettes.

My palette setting program loops through the palette numbers from 0 to 4095 and decomposes them into bits B0,B1,B2,B3,R0,R1,R2,R3,G0,G1,G2,G3 by the above formula . Then, according to the above rules, the PLTPG0 or PLTPG1 table is referenced and the BRG is set to the corresponding pallet number.

[pser1]

Hello,
I have been playing drawing rectangles using only one page in mode TYPE_B
The program first draws four big rectangles with four grades of Blue, the grades are fixed on page 0 to be: 0,4,8,12 because we are using
bits 2 and 3. Then it draws eight horizontal stripes with RED values 0,4,8,12,0,4,8,12
And finally it adds 8 vertical rectangles with green values 0,4,8,12,0,4,8,12. The results of each step are shown in attached images

4 Colours Blue Page0.jpg (7.01 KiB) Visto 596 veces

16 colours BlueRed Page0.jpg (9.15 KiB) Visto 596 veces

64 colours BRG Page0.jpg (10.52 KiB) Visto 596 veces

Besides I have tested the same program drawing in Page 1 where bits 0 and 1 are used, giving values 0,1,2,3 as possible grades for each colour
The result is very dark compared to the one in page 0. See attached image too

64 colours BRG Page1.jpg (8.06 KiB) Visto 596 veces

Next test-experiment has included the subroutine that calculates the palette values for the 4096 colours and has the two tables of 64 selected colours for page 0 and 1. These tables contain the value for the three components that are sent to FD32-33-34
Besides I have added one table for each page that contains a word for each entry corresponding to the colour code from 0 to 4096 (64 entries)
Then the program points to the table for Page 1 and sequentially reads a word and converts it into bits G1,G0,R1,R0,B1,B0 and once calculated
it sets accordingly the pixels in a rectangle 5 bytes wide and 25 pixels high putting each rectangle next to previous
Much to my surprise, the screen stays always black ...

Then I have commented out the call to the subroutine that fills the palette (4096) and when run, then 64 colours have appeared!
I attach here the image, with different colours because the list of colours to be shown is not the same. The asm source file is included too.

64ColoursWithoutPalette Page 0.jpg (9.71 KiB) Visto 596 veces

Testing 64 colours.zip

Source files in asm

(8.62 KiB) Descargado 8 veces

I am sure that I am forgetting a step or something that will let the program show the colors on screen ...
Any hint will be appreciated!

cheers!
pere

[pser1]

Hi,
just for the fun of it, I have made another test ...
I have substituted Malik's subroutine that sends data to FD32-34 by the one that comes in page 37 of Oh!FM 1986,January
As Malik said, that one maps the 4096 colours evenly on the 64 colours in our palette
The result is that the 64 colours have appeared on screen without issues, see atached image
So, there must be something I am doing wrongly when using the other method
cheers!
pere

64 Colours using Sbr from OhFM.jpg (21.38 KiB) Visto 591 veces

64ColoursAnotherWay.ZIP

(5.06 KiB) Descargado 6 veces

[pser1]

Hello,
well, once done these last tests, we can say that it is easy to have 64 colours on one Page (2 bits per colour)
but this relays on the 4096 std colours and we just use bits 2,3 in order to have bright colours, the cost is that
white colour is not clean as we are using values 0,4,8,12 and white needs 15,15,15 to be true.

And the last point, to write on foreground page, is it enough to have the second table of 64 entries and use
them the same way I have been using the one for the background in my examples?
Or is there a special procedure to write on foreground Page?
In fact the background should be sent to Page 1 (with bits 0-1) and the foreground to Page 0 (bits 2-3)
cheers!
pere

[pser1]

Hello,
finally I understood the messages that Malik has posted here concerning the dual 64 colour mode.
Right now I have a program that fills the background with 64 colours and then draws three contiguous rectangles
of different colour in the foreground page.
Moving them with QAOP as usual, you can see that background is not affected at all!
By the way, remember that the moves require CAPS activated. I am comparing to uppercase only ...
The problem now is knowing how to move the let's say 'player' without flickering.
On the Dragon we insert a sync opcode before drawing so that this only happens on the retrace time, so out of screen ...
How could we do the same here?
I attach the source code and the virtual disk for anyone wanting to test it ...
cheers
pere

TEST08B.zip

(58.92 KiB) Descargado 49 veces

Dual 64colour Mode.jpg (10.51 KiB) Visto 565 veces

Ps the colour degradation is due to the size reduction I do apply to the screenshot to make it appear instead of just showing
the file name ...

[jltursan]

The problem now is knowing how to move the let's say 'player' without flickering.
On the Dragon we insert a sync opcode before drawing so that this only happens on the retrace time, so out of screen ...
How could we do the same here?

I'm not sure; but I think you can do a vblank synchronization reading bit 0 of the SUBSTAT register ($FD12).

[pser1]

Even doing so the flickering doesn't disappear.
At the beginning of the FG painting I have added
1. LDA SUBMSR. ; $fd12
BITA. #1
BEQ. 1B
Have tested with BNE too but the result was worse
The points are added by the mobile
Cheers
Pere

[jltursan]

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 (175.21 KiB) Visto 529 veces

[malikto999]

Then the program points to the table for Page 1 and sequentially reads a word and converts it into bits G1,G0,R1,R0,B1,B0 and once calculated
it sets accordingly the pixels in a rectangle 5 bytes wide and 25 pixels high putting each rectangle next to previous
Much to my surprise, the screen stays always black ...

Then I have commented out the call to the subroutine that fills the palette (4096) and when run, then 64 colours have appeared!
I attach here the image, with different colours because the list of colours to be shown is not the same. The asm source file is included too.
64ColoursWithoutPalette Page 0.jpg
Testing 64 colours.zip
I am sure that I am forgetting a step or something that will let the program show the colors on screen ...
Any hint will be appreciated!

Regarding the above matter, I was continuing to verify. As a result, I was able to reproduce the black screen you reported.

In FBASIC 3.0, strangely after running my palette setup code after changing the subsystem mode to type B, writing to VRAM was disabled.
The palette was set, but even if the value was written to VRAM, it remained 0, so nothing was displayed on the screen.

I don't know what causes the above phenomenon. I can't tell if it happens on the actual machine or if it's a phenomenon specific to the emulator. It may be a timing problem due to batch palette change in FBASIC V3.0.

I was able to avoid the above phenomenon by changing the subsystem mode after setting the palette. Start the attached disk and execute LOADM"PAL64X",,R. You can see that PAGE0 and PAGE1 draw patterns using their respective palettes.

[malikto999]

:-(
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.

[jimbobaby]

Hi

I'm curious and only trying to help a little. Maybe whatever i say is irrelevant or already known. Right now i'm trying to load Pere's disks on the mutsu emulator and i'm still unable to do so , but that's not the point. So, for what it's worth...

Using my smartphone (a normal android one, nothing fancy), you can download google lens and google translator, open translator app, download the japanese "module", and point the camera to the image you want to translate. And it does a "in place" real time translation (if it's good or not i'm not able to interpret)

I have done it with the last scanned image snip, and the results are, more or less (from left to right) "FD12, submode status register, R/W/rst, AV system, VSYNC status, 1:Synchronous between".

So, from what i understand, 1 while on vsync.

Also, there is a message from malikto999 (viewtopic.php?t=200033117&start=96#p200084558), where it says...

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)

I don't undestand why there are TWO vsyncs, but also it's not usual to have a cpu doing the gpu's job, so...