FM77AV - learning how to program it (english thread)

[jltursan]

Último mensaje de la página anterior:

Here's a recreation of the 63C09 card:

富士通 FM-7/77用HD63C09Eカード製作 その1

Oops, malikto999 already posted the same link

...but no schematic or Gerbers are made public. No GAL jed files either...

It's a really cool hardware. Seems that it can be switched to even 6Mhz!. Here're some benchmarks

Btw, I can't see too many socketed chips in the 77AV. I'm afraid that you'll need to desolder the CPUs just to test it .

The FM77AV40SX has some kind of "turbo" mode (only two POKE commands or pressing TAB when booting) just disabling some wait states when using the MMR. Seems that the gain is about a 25%. I've tested it and it really works.

EDIT: Oh, and I've tested the replacement of the main/sub CPUs of the FM-7. Replacing the main CPU with a HD63B09P gives me a flashing cursor and nothing more. If I replace the SUB cpu, only black screen.
...and guess what?, it's the same behaviour that I get when I try with a HD63C09EP(the CoCo/Dragon ones); so I'm 99% sure that I've a nice batch of fake chinese HD63B09P CPUs! ,all of them are, probably, EP CPUs

[malikto999]

I will write about the analog palette function as a prerequisite for the 64-color dual-screen mode.

The analog palette of FM77AV can set any color from 4096 colors for palette codes from 0 to 4095.
(Of course, this function is only for subsystem type B.)

The analog palette is located in $FD30-$FD34 of the main I/O and has the following meanings.

+------------------------------------------------------------+
|ADDR | R/W | b7 | b6 | b5 | b4 | b3 | b2 | b1 | b0 |
+------------------------------------------------------------+
|$FD30 | W | 0 | 0 | 0 | 0 | LC11| LC10| LC9 | LC8 |
------------------------------------------------------------
|$FD31 | W | LC7 | LC6 | LC5 | LC4 | LC3 | LC2 | LC1 | LC0 |
+------------------------------------------------------------+

Specify an analog palette code from 0 to 4095 with 12 bits from LC0 to LC11.
Then set the brightness levels​of blue, red, and green in three registers with values​from 0 to 15.

+------------------------------------+
|ADDR | R/W | b3 | b2 | b1 | b0 |
+------------------------------------+
|$FD32 | W | BL3 | BL2 | BL1 | BL0 |
+------------------------------------+
|$FD33 | W | RL3 | RL2 | RL1 | RL0 |
+------------------------------------+
|$FD34 | W | GL3 | GL2 | GL1 | GL0 |
+------------------------------------+

The relationship between the analog palette and VRAM is as follows.
VRAM has 2 pages, and page 0 has plains B3, B2, R3, R2, G3, and G2.
Page 1 has plains B1, B0, R1, R0, G1, G0.

Bits LC0 through LC11 of the analog palette code correspond to VRAM plains as follows:
LC0-LC3 <- B0-B3
LC4-LC7 <- R0-R3
LC8-LC11 <- G0-G3

That is, the formula for converting the BRG bit of VRAM to palette code is as follows.

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

In the 64-color dual-screen mode, in the above formula, set the palette so that the color of page1 is displayed when all bits(B3, B2, R3, R2, G3, G2) of page0 are 0.
On the other hand, if any bit is 1 in page0, set the palette to display page0 colors.
(When page 0 is the character and page 1 is the background)

In this state, if you draw a background pattern on page 1 and a character pattern on page 0, the background page 1 will be displayed only where all bits of page 0 are 0 (that is, transparent color).

I will write the specific setting method next time. (may take a while)

[pser1]

Cool!, once scanned you can try with Capture2Text. It gives great results and has a handy interface, maybe not the most common but really great when you need a quick translation.

Hello jltursan,
I have just received the magazine and was making the first test.
First of all, despite the magazine looks nice, the pages don't help to be put in a plane to take a clean photo.
I have taken one and wanted to process with Capture2Text ...
Once started the app it seems to stay resident, so I have open the 'photo' and pressed Windows+Q, then the cursor
tells me where it is and so I drag the mouse to mark a rectangle full with japanese characters.
Once I press the mouse button it begins to do some work and finally it shows a small text window
but only with japanese chars and these are not the ones I have on screen
It seems that I am doing more than one step wrongly. Could you suggest me a better procedure?
And what resolution should have the photo for the OCR to work properly?
How should I tell the program to make the translation from japanese to english?
thanks in advance
cheers!
pere

[jltursan]

As an example, I've OCR'ed a small portion of an I/O magazine:

Capture2Text_01.png (367.67 KiB) Visto 1254 veces

As you can see, the results are mostly good. The PDF has a resolution of 100DPI, so a page is about 712x1012 pixels with a good scannig quality. The capture has been done with full width.

To configure the software you only need to open the settings and select your OCR language in the "OCR 1" tab and the desired translation behaviour in the "Translate" tab.

[pser1]

As an example, I've OCR'ed a small portion of an I/O magazine:
As you can see, the results are mostly good. The PDF has a resolution of 100DPI, so a page is about 712x1012 pixels with a good scannig quality. The capture has been done with full width.
To configure the software you only need to open the settings and select your OCR language in the "OCR 1" tab and the desired translation behaviour in the "Translate" tab.

I have just used those options in the configuration tab of the program.
When I select a small window of the screen image, the window that is open shows
- japanese text that is not what I see in the screen
- the english translation is really awful
I did not scan the magazine to avoid damaging it, so I just took a photo of a page.
The image in the PC viewer shows that it is just 72dpi but of course I would never say that the photo is of
any good quality
So I am afraid that scanning is going to be the only way, pity!
cheers!
pere
Ps Anyway, for maybe you'd want to give it a try, I am adding here zipped that test image ...

ScanRevista8512-01.zip

(5.11 MiB) Descargado 24 veces

[pser1]

I see that even zooming the image a lot, the result of both parts, say japanese recognition (OCR)
and later translation is so awful that I think that using mobile as camera is not going to work at all
pere

[jltursan]

The quality is not enough, zooming you can clearly see that a lot of kanjis are very blurry. Don't ake a full page photo, take only a picture of half page or even a quarter and use minimal compression. Also try to take the picture right above the magazine, don't tilt the phone.

If you don't have a scanner, I'm sure you can still use your phone camera...

[pser1]

The quality is not enough, zooming you can clearly see that a lot of kanjis are very blurry. Don't ake a full page photo, take only a picture of half page or even a quarter and use minimal compression. Also try to take the picture right above the magazine, don't tilt the phone.
If you don't have a scanner, I'm sure you can still use your phone camera...

I have a printer-scanner and I do use it very often but due to the state of the magazine I was trying to avoid opening it in full (180º)
to scan every page ...But if there is no other way, I'll do that!
Of course, first will try to modify the configuration of my mobile to see if it can get better pictures and besides that, taking
photos of half page seems interesting, not sure if getting just quarters would help that much
cheers!
pere

[pser1]

@malikto999
So in TYPE_B, if we fill $FD30-$FD31 with the 12 bits that correspond to a colour code out of 0-4096
and then we enter the level for B-R-G respectively into $FD32-33-34 the system will save that value somewhere.
I asume that the system will save any other BRG we enter after selecting a different colour code in FD30-31
If this is the case, where are these combinations saved?
How could we use them instead of 'setting' or 'resetting' bits in the three planes using the MMR directly writing the VRAM?
Not sure if this would be possible, maybe it was a way to explain how to prepare the system for the dual 64 colours mode ...
cheers!
pere

[pser1]

Hello,
looking at the magazines I won, I have found a lot of info about the FM77AV on the 1985,December issue
And the 1986, January issue seems to have the I/O map too (as the 1989, May) if I am not wrong
I tried to scan a page but due to the bad state of the magazine, even at 600dpi the result was painful
So I have decided to take fotos by columns, so three per page.
I will let you know the progress on this translation ...
cheers!
pere

[pser1]

@jltursan
Concerning the use of the drives of this machine that you explained in another thread that they begin to show some problems,
and remembering the problems I had with one of the drives on the FM7, I was thinking that maybe we could analyze the chances
to use an HxC module to emulate two drives more, say number 2 and 3
This would help us a lot when coming to create physical copies of floppy drives without the need to buy a Greaseweazle
We could easily put the images on SD or pen drive and use the HxC as we do with the CoCo-SDC (I asume it would be possible)
but that's another story that probably should requiere an individual thread for it to avoid overloading contents in that one
cheers!
pere

[jltursan]

@jltursan
I was thinking that maybe we could analyze the chances
to use an HxC module to emulate two drives more, say number 2 and 3
This would help us a lot when coming to create physical copies of floppy drives without the need to buy a Greaseweazle
We could easily put the images on SD or pen drive and use the HxC as we do with the CoCo-SDC (I asume it would be possible)
but that's another story that probably should requiere an individual thread for it to avoid overloading contents in that one
cheers!
pere

Done: To connect an HxC or Gotek+FlashFloppy unit

[malikto999]

It's been a while since my last post.

So in TYPE_B, if we fill $FD30-$FD31 with the 12 bits that correspond to a colour code out of 0-4096
and then we enter the level for B-R-G respectively into $FD32-33-34 the system will save that value somewhere.
I asume that the system will save any other BRG we enter after selecting a different colour code in FD30-31
If this is the case, where are these combinations saved?

$FD30-$FD34 are write-only, and I don't think there is a way to get the value of the analog palette already set.
I manage the color setting information for the 64-color palette by creating a work table.
Please refer to the attached "PAL64S.ASM" file.

Page0 and Page1 each have a table for 64 colors. (PLTPG0, PLTPG1)
The structure of the table is free, but in my sample each color has 3 bytes of BRG.
In this BRG, color assigned to the 64-color palette is specified from 0 to 15 levels.

Each color in the table is assigned a serial number from 0 to 63.
This serial number is directly tied to the 4096 color palette code and VRAM it should be written to.
For example, if you want to display the 57th color of the 64-color palette in the foreground of the screen, set the G3, G2, R3, and B2 bits of VRAM Page0 to 1, and set the R2 and B3 bits to 0.
(See comments in the source.)

As a sample of 64-color 2-screen mode, I would like to show you how to superimpose and erase operations using BASIC's LINE statement.

1. Start FBASIC V3.3 with FBASIC33.D77 in the attached file.
2. Run the BASIC program with RUN"PAL64".
3. The 64-color tile pattern of PLTPG1 table is drawn on the background (Page1). Please press any key.
4. Draw a box in the foreground (Page0) with color 6 of PLTPG0 table. Please press any key.
5. The foreground box is erased. Press any key to exit.

In step 5 above, you can see that erasing the foreground does not affect the background.

Since BASIC's LINE statement does not have a function to draw for each page, I specify "OR" when drawing a box and "XOR" when erasing it so as not to overwrite the background page.
(Of course, when writing VRAM directly by yourself, such considerations are not necessary.)

[pser1]

@malikto999
Hello,
I have downloaded the zip and tested the basic program. It works perfectly, thanks for the explanations!

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)

How could we restore the old behaviour?
cheers!
pere

[pser1]

@malikto999
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)
How could we restore the old behaviour?

Answering myself
I have added the basic program AUTOUTY to the TEMPLATE I do use for the test virtual files and then once mounted in drive 0
I have run the program and set (again) 2 drives and 15 files ...
Once done this, the 'old' .d77 disks do work without issues
So, how could we avoid FBASIC33 changing these params and maybe others?
cheers
pere

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

[malikto999]

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
I don't know how could it happen, but after running the PAL64 example, the old disks (.d77) that autostarted
without issues did not work anymore
But just running AUTOUTY again on them and setting drives, files again did the trick and now they work flawlessly
I just did that once on a TEMPLATE.d77 file that I copy when compiling a test program.

I have found that many articles in the Oh!FM magazine do relay on FBASIC3.3
That's the reason I asked if a ROM version of it does exist. No problem using the .d77
cheers!
pere