FM77AV - learning how to program it (english thread)

[pser1]

Último mensaje de la página anterior:

I issued LOADM"LOADX",,R
and screen didn't change ... just black

I have tried and i see the file (backdata) and executing the program i see alternate vertical bars of black and red filling the whole screen. Pressing Q to exit.
From what i see on source, is loading data directly from disk sector by sector

Thx,
will download again the file for maybe it got corrupted the very first time.
cheers!
pere

[pser1]

now time to have a read to the LOADX.ASM file
At first it seems to use the ROM only to fill some DOS working areas and thereafter it switches to RAM mode, so disabling the FBASIC.
From that point on, everything is done in pure assembler. Anyway it seems fast enough!
cheers!
pere

[malikto999]

I will explain the processing contents of LOADX that was uploaded last time.

FBASIC manages disk files in cluster units. One cluster contains 8 sectors. In other words, the size of one cluster is 2048 bytes.
The size of the background bitmap file in this sample is $8000 (32768) bytes, so it occupies 16 clusters.

Clusters are managed in a chain structure in a FAT table. The cluster at the beginning of the file is also saved in a directory slot.

Each ROM routine within the FOPEN subroutine reads the FAT table and directory slot for the target file.
The parameters when calling the ROM routine are as follows.

$2E6: Drive number (0: $80, 1: $81)
$2DD:File name length (1-8)
$2DE-$2E5:File name

Once this is done, there is no need for the BASIC ROM. Subsequent processing can be executed in RAM mode.

The LOADX and READ2CL subroutines sequentially retrieve clusters from FAT and read sectors sequentially into the disk buffer allocated at $8000-$8FFF.
VRAM is allocated to $8000-$8FFF using direct access, so as a result, the disk writes directly to VRAM.

Within the DSKIN subroutine, call the BOOT ROM sector I/O routine ($FE08).
At this time, pass the 8-byte DCB parameter. The contents are as stated below.

DCB+0:Dummy
DCB+1:Dummy
DCB+2:Disk buffer address
DCB+4:Track (0-39)
DCB+5:Sector (1-16)
DCB+6:Side (0-1)
DCB+7:Drive

The SETTSSN subroutine converts clusters to tracks/sectors/sides. At the same time, the next cluster number is obtained from FAT.
If the cluster number is $C0-$C7, it is the final cluster. (0-7 is the last sector)
The size of the background bitmap file in this sample is fixed, so there is no need to check the end of the file. Also, there is no need to close the file for reading processing.

If you have any questions about the above, please ask.

[pser1]

If you have any questions about the above, please ask.

Hi,
thanks a lot for your kind explanations. The Disk Operating System, being made by Microsoft, uses the disk space the same way it does for the
CoCo computers. Dragon DOS is absolutely different, for instance each track has 18 sectors and there is no 1st cluster associated to the directory entry, instead the whole list of used sectors is included in the directory entry ...
The program works flawlessly and will be perfect for program/games that use the whole screen, say 320x200
; -----------------------------------------------------------------------------------------------------------
But, when converting Shark/Tiburón for the FM77AV, we must stick to the Dragon resolution, unless we do change all of the screens,
this means using 256x156 with uses only 4992 bytes and worst of all, they are not contiguous. After each line (32 bytes) there must be 8 zero bytes
to skip the not used VRAM area on the right of the screen.
Probably we could pad these lines with the 8 zeroes so that they could be read straight away without calculations needed to fill each plane
Doing so will create screens 320x156 using 6240 bytes that's a 25% extra space used, but I think we can asume it ...
Using that patched file, we would need to read 24 sectors per plane.
Every plane change will need, mandatory, a bit of code to skip the unused lines from 157 till 200, changing the VRAM mapping to the
begining of each plane. Seems doable!
The last pitfall is the fact that the image file will come with the palette at the beginning, say 1 sector (256 bytes)
As we will be working in RAM mode, I was thinking of changing the address of the read buffer for the DOS, setting it to $7F00 instead of $8000
and then for each plane change we will set it at $8000. Of course the very first pass we should read 7 sectors instead of just 6.
That way we could use the palette that would stay in RAM while the plane contents will be redirected to VRAM
I am just thinking out loud.
Any hint/observation about that brainstorming will be highly appreciated
I know that part of this should fit better in the Shark thread, but asking for technical support seems better here, I hope
cheers!
pere

[jimbobaby]

Any hint/observation about that brainstorming will be highly appreciated

The best should be redo the graphics on the target resolution (and more so if they need to be "colorized") , but i'm not an artist

If not, i would chose the continous file (no gaps between lines) and palette at the very last. Not read clusters directly into VRAM, but a RAM buffer, and move the data in place (leaving the gaps on the fly) afterwards.

Disclaimer: i confess that i have not studied the code yet, i don't know if DMA is possible, i don't know if you can read only a bunch of sectors and not a full cluster, and i don't know the ideal number of sectors to read "on one go" to maximize drive speed (i would think the more the better, but...dunno ).

Also, i don't know how many screens have the game to be stored on disk (to see if there is space to spare or not)

Also, using a small buffer to read in chunks and transfer to VRAM, could also use some cheap compression like RLE (run lenght encoding) to read less data from disk and use more CPU. All is a tradeoff.

Whatever the option chosen, i would set the palette right at the end (and "blank it" with all blacks -or all whites in this case- just before start loading the screen), to gain time (so you don't see the screen while drawing, regardless of the loading speed).

My two cents

[pser1]

Any hint/observation about that brainstorming will be highly appreciated

The best should be redo the graphics on the target resolution (and more so if they need to be "colorized") , but i'm not an artist

Nor am I, this is totally out of my control, so let's use what we have right now!

If not, i would chose the continous file (no gaps between lines) and palette at the very last. Not read clusters directly into VRAM, but a RAM buffer, and move the data in place (leaving the gaps on the fly) afterwards.

This is how I do load the fruity image in my demo PAL1615L but using two files for space reasons

Disclaimer: i confess that i have not studied the code yet, i don't know if DMA is possible, i don't know if you can read only a bunch of sectors and not a full cluster, and i don't know the ideal number of sectors to read "on one go" to maximize drive speed (i would think the more the better, but...dunno ).

Well, no DMA if I am not wrong. But most of these technical questions should better be answered by malikto999 who
knows the machine way better than all of us!

Also, i don't know how many screens have the game to be stored on disk (to see if there is space to spare or not)

Minimum 13 screens if we try to use the other characters (apart from Brody) as sprites too. If not, then number of screens could go up to more than 20

Also, using a small buffer to read in chunks and transfer to VRAM, could also use some cheap compression like RLE (run lenght encoding) to read less data from disk and use more CPU. All is a tradeoff.

Not sure if moving data twice would be any faster than sending it right to the VRAM. We should make some tests to compare ...

Whatever the option chosen, i would set the palette right at the end (and "blank it" with all blacks -or all whites in this case- just before start loading the screen), to gain time (so you don't see the screen while drawing, regardless of the loading speed).

I cannot spot the difference putting the palette at the beginning or at the end of the file ...
cheers!
pere

[malikto999]

I think the only way to find the best loading and drawing method for the pattern format is through trial and error.
In the case of an emulator, it is difficult to measure the speed of disk access, but in the case of XM7 there is an "Inser wait cycles during FDD access" item in the settings. (Even if you check this, I think it's still faster than the actual machine...)

There is no need to insist on loading directly to VRAM, but if the background bitmap does not match the VRAM, I think it is better to separate the loading process and drawing process. (If simple transcription is not possible, I think there is a speed risk in drawing while loading.)

By the way, even if you switch to RAM mode, the DISK BASIC add-on code and system stack will remain in $7000-$7FFF. It's a hindrance, isn't it?
Since it is better to use a wide range of contiguous memory, how about temporarily moving the system stack to the end of the address and allocating the unused memory of $00000-$0FFFF to $6000-$7FFF?

CLR $FD0F ;ram mode
STS SSTACK
LDS #$FC80
LDD #$0001
STD $FD86 ;$6000-$7FFF <- $00000-$01FFF

...

LDD #$3637
STD $FD86 ;$6000-$7FFF <- $36000-$37FFF
LDS SSTACK
TST $FD0F ;rom mode

*There is a possibility that the system stack points before $6FFF, so switch $6000-$6FFF as well.

If you do this, you won't need to assign MMR piecemeal when loading a pattern or expanding it to VRAM.

[malikto999]

Disclaimer: i confess that i have not studied the code yet, i don't know if DMA is possible, i don't know if you can read only a bunch of sectors and not a full cluster, and i don't know the ideal number of sectors to read "on one go" to maximize drive speed (i would think the more the better, but...dunno ).

Also, i don't know how many screens have the game to be stored on disk (to see if there is space to spare or not)

Also, using a small buffer to read in chunks and transfer to VRAM, could also use some cheap compression like RLE (run lenght encoding) to read less data from disk and use more CPU. All is a tradeoff.

The larger the data size, the longer it will take to access the disk, so data compression may ultimately be the best solution, but it is quite difficult to overcome.

My personal opinion is that unless it's a simple copy, we should avoid reading part of the data and drawing part of it repeatedly.
It's not cool to have the background drawn gradually, and it also complicates the code.

Fortunately, FM77 has plenty of memory and can write directly to VRAM, so I think it's a good idea to load all the data and then transfer it to VRAM.

Whatever the option chosen, i would set the palette right at the end (and "blank it" with all blacks -or all whites in this case- just before start loading the screen), to gain time (so you don't see the screen while drawing, regardless of the loading speed).

What is the purpose of this? Is it to not show the drawing process in progress?

[pser1]

I think the only way to find the best loading and drawing method for the pattern format is through trial and error.
In the case of an emulator, it is difficult to measure the speed of disk access, but in the case of XM7 there is an "Inser wait cycles during FDD access" item in the settings. (Even if you check this, I think it's still faster than the actual machine...)

I do agree, so I hope to make some tests loading the fruity image I had used ...

There is no need to insist on loading directly to VRAM, but if the background bitmap does not match the VRAM, I think it is better to separate the loading process and drawing process. (If simple transcription is not possible, I think there is a speed risk in drawing while loading.)

For the Shark game, the screen doesn't match the VRAM as it is just 256x156. The only chances would be padding every line with 8 zeroes, so 25% more space or loading to RAM and then stackblasting to maped VRAM.

By the way, even if you switch to RAM mode, the DISK BASIC add-on code and system stack will remain in $7000-$7FFF. It's a hindrance, isn't it?
Since it is better to use a wide range of contiguous memory, how about temporarily moving the system stack to the end of the address and allocating the unused memory of $00000-$0FFFF to $6000-$7FFF?

Código: Seleccionar todo

  CLR     $FD0F       ;ram mode
  STS     SSTACK
  LDS     #$FC80
  LDD     #$0001
  STD     $FD86       ;$6000-$7FFF <- $00000-$01FFF
  ...
  LDD     #$3637
  STD     $FD86       ;$6000-$7FFF <- $36000-$37FFF
  LDS     SSTACK
  TST     $FD0F       ;rom mode

*There is a possibility that the system stack points before $6FFF, so switch $6000-$6FFF as well.
If you do this, you won't need to assign MMR piecemeal when loading a pattern or expanding it to VRAM.

This could be a great idea. must try it!
cheers!
pere

[pser1]

@malikto999
Hello,
1) on the FM77AV I don't use any of the system variables from page 0 ($0000-$00FF) that could be used if we don't call ROM functions,
allowing us to use the 'direct' addressing method that is much faster than the extended one ...
Is there any documentation that explains the system use of the area $0000-$03FF or whatever is used in the FM77AV?

2) for the CoCo and Dragon we have access to documents that contain the whole Basic ROM unassembled with comments!
Even the Disk Operating System exists unassembled with some comments
Is there any chance to find such kind of documentation for the FM77AV FBasic3.0 and Disk Operating System?

3) In your LOADX example, we switch to RAM mode before reading data from disk. Then we do not call FBASIC subroutines/functions
but we call system functions, say $FE02 and $FE08. I asume that these are BIOS functions that stay in the subsystem ROM, is this correct?
I think I had read somewhere that the I/O is performed by the subsystem.
If that is true, it would be nice to know what functions are allowed to the programmer and what parameters do they expect to receive

4) The FBASIC30.ROM contains all of the code for Basic and Disk, I hope. It is about 32Kb long
There are some subsystem ROMs:
SUBSYS_A.ROM, SUBSYS_B.ROM, SUBSYS_C.ROM, SUBSYSCG.ROM
The first three would be used upon the mode TYPE we chose, but when is it used the very last one?

5) The INITIATE.ROM in the XM7 folder, where does it 'live' in Memory of an actual machine? I mean what addresses does it occupy?

thanks in advance
pere

[malikto999]

1) on the FM77AV I don't use any of the system variables from page 0 ($0000-$00FF) that could be used if we don't call ROM functions,
allowing us to use the 'direct' addressing method that is much faster than the extended one ...
Is there any documentation that explains the system use of the area $0000-$03FF or whatever is used in the FM77AV?

When using FBASIC V3.0, there is no need to be aware of the differences between the FM-7 and FM77AV models.
The work area starting from address $0000, the DISK BASIC add-on from $7000 to $7FFF, and the BASIC ROM starting from address $8000 are common to the FM-7 series.

"FM-7 F-BASIC ANALYTICAL MANUAL" series is the most detailed internal document for FBASIC V3.0.
You can download the PDF file from the link below.

FM-7 F-BASIC ANALYTICAL MANUAL Phase I Basic Edition
https://archive.org/details/fbasici
FM-7 F-BASIC ANALYTICAL MANUAL Phase II Exploration Edition
https://archive.org/details/fbasicii
FM-7 F-BASIC ANALYTICAL MANUAL Phase III Subsystem Edition
https://archive.org/details/f-basic-iii
*The subsystem edition is an analysis book for the FM-7's TYPE-C subsystem, so it does not support the new subsystem of the FM77AV.

The information you want to know is in the appendix of the exploration edition. Please refer to "6-1 Work area list".

2) for the CoCo and Dragon we have access to documents that contain the whole Basic ROM unassembled with comments!
Even the Disk Operating System exists unassembled with some comments
Is there any chance to find such kind of documentation for the FM77AV FBasic3.0 and Disk Operating System?

I have never seen the assembler source for the entire BASIC. The above book contains detailed information about the main subroutine entries and their processing contents, so I disassemble and check them when necessary.
Japanese may be a problem for you. The memory map for BASIC-ROM and DISK BASIC is included in the appendix of the exploration edition, so I think it would be a good idea to use it to find the entry for the desired process and translate the body text.

3) In your LOADX example, we switch to RAM mode before reading data from disk. Then we do not call FBASIC subroutines/functions
but we call system functions, say $FE02 and $FE08. I asume that these are BIOS functions that stay in the subsystem ROM, is this correct?
I think I had read somewhere that the I/O is performed by the subsystem.
If that is true, it would be nice to know what functions are allowed to the programmer and what parameters do they expect to receive

The devices managed by the subsystem are the screen, keyboard, and timer (clock). Auxiliary storage devices (tapes, floppy disks) are under the control of the main CPU. Disk I/O routines are contained in the BOOT ROM (not the subsystem ROM) starting at $FE00. This area is not affected by ROM/RAM mode switching.
When it comes to disks, there are functions such as sector READ/WRITE and seek track. A detailed explanation will be long, so I'll post it in a separate reply. Would the FM-7 thread be better?

4) The FBASIC30.ROM contains all of the code for Basic and Disk, I hope. It is about 32Kb long
There are some subsystem ROMs:
SUBSYS_A.ROM, SUBSYS_B.ROM, SUBSYS_C.ROM, SUBSYSCG.ROM
The first three would be used upon the mode TYPE we chose, but when is it used the very last one?

5) The INITIATE.ROM in the XM7 folder, where does it 'live' in Memory of an actual machine? I mean what addresses does it occupy?

I thought that SUBSYSTEM.CG contained hiragana fonts and that INITIATE.ROM was temporarily loaded into memory when FM77AV was started, but my memory is fuzzy. I'll look into it and comment again.

[jimbobaby]

Japanese may be a problem for you. The memory map for BASIC-ROM and DISK BASIC is included in the appendix of the exploration edition, so I think it would be a good idea to use it to find the entry for the desired process and translate the body text.

Speaking about that, lately i'm doing some tests, and i'm astonished at the current level of google translate. For now, it's a bit cumbersome, but i can extract pages from a pdf (they are scanned pdf's afterall, not pure text, only a full image for every page), resize them to 4 times bigger (integer scaling, no distortion through interpolation, just more resolution) and pass them directly one by one thought google translate website. The results are good enough (surely waaaaaay better than my japanese ). But, as i say, it's not automated and cumbersome.

It would be increible if it could be automated to translate full pdf's directly, but for now... As i say, it really needs the pre-upscaling of the images, or the results are unreadable for the most part.

Disclaimer: I don't know if there is any kind of limit about quantity of free translation. I have read about 500k words, but i don't know if/how they enforce it when using it without login (by ip address? i don't know)

[jimbobaby]

I thought that SUBSYSTEM.CG contained hiragana fonts and that INITIATE.ROM was temporarily loaded into memory when FM77AV was started, but my memory is fuzzy. I'll look into it and comment again.

From emulator notes (CSP-fm7, https://github.com/Artanejp/common_sour ... ree/master):

Código: Seleccionar todo

  Required for FM-7 and above:
  BOOT_BAS.ROM : 512 bytes, BASIC boot ROM.
  BOOT_DOS.ROM : 512 bytes, DOS (NOT MS-DOS) boot ROM.
  FBASIC302.ROM
  FBASIC300.ROM
  FBASIC30.ROM: 31744 bytes, F-BASIC 3.0 (one of the above three).
                 A substitute ROM is available. .
  SUBSYS_C.ROM : 10240 bytes, subsystem monitor type C.

  As an additional ROM:
  KANJI.ROM
  KANJI1.ROM: 131072 bytes, JIS first level kanji pattern.
  BOOT_MMR.ROM : 512 bytes, hidden boot ROM for FM-77 (unchecked).

  Additional ROM (FM77L4 only)
  SUBSYS_L4.ROM : 18432 bytes. 400 line card system ROM.
  ANKCG16.ROM : 4096 bytes. Character data for 400 line cards.
 
  FM77AV also requires:
  INITIATE.ROM : 8192 bytes, initiator ROM.
                 This definitely needs to be from the FM77AV.
       It does not work with 77AV20/40 series.
  SUBSYSCG.ROM: 8192 bytes, character data ROM.
  SUBSYS_A.ROM : 8192 bytes, Subsystem monitor type A.
  SUBSYS_B.ROM : 8192 bytes, Subsystem monitor type B.

  Additional ROM (for FM77AV20/40 only):
  KANJI2.ROM: 131072 bytes, JIS level 2 kanji pattern.
  DICROM.ROM: 262144 bytes, Kana-Kanji conversion dictionary ROM.
  EXTSUB.ROM: 49152 bytes, extended sub monitor (77AV20 or later)

  For FM77AV20/40/EX/SX, INITIATE.ROM is specific to AV20/40/EX/SX.
  please use it.

And more specificaly:

Código: Seleccionar todo

--- Internal ROM image

    Main SYSTEM:
   BOOT_BAS.ROM    $FE00 - $FFFF BOOT ROM(Basic Mode / optional)
   BOOT_DOS.ROM    $FE00 - $FFFF BOOT ROM(Dos Mode / optional)
   BOOT_DOS.ROM    $FE00 - $FFFF BOOT ROM(MMR Mode / optional)
   INITIATE.ROM   $6000 - $7FFF Initiator ROM.
                        You MUST real machine's initiator ROM.
                  i.e) If you use 77AV's initiator ROM to
                  eFM77AV40, eFM77AV40 will not boot.



[pser1]

When it comes to disks, there are functions such as sector READ/WRITE and seek track. A detailed explanation will be long, so I'll post it in a separate reply. Would the FM-7 thread be better?

You are right, I agree that anything shared for both machines (FM-7 and FM77AV) would fit better in the FM-7, that way we will have
info 'better' classified whenever we need to search for anything ...
The three docs "Analytical Manuals" seem to have great info!
thanks a lot
cheers!
pere

[malikto999]

4) The FBASIC30.ROM contains all of the code for Basic and Disk, I hope. It is about 32Kb long
There are some subsystem ROMs:
SUBSYS_A.ROM, SUBSYS_B.ROM, SUBSYS_C.ROM, SUBSYSCG.ROM
The first three would be used upon the mode TYPE we chose, but when is it used the very last one?

The SUBSYSCG.ROM of XM7 is the file that sucked out $D800-$D8FF of the sub CPU memory of FM77AV. There are 4 banks of memory at this address, resulting in a 4*$800=8192 byte file.

Two of the four banks are part of sub-monitors A and B, and the remaining two are katakana and hiragana character ROMs. (In FM-7, this was only the katakana ROM.)
There is no need to be aware of the sub monitor bank switching as the system will do it for you. The character ROM can be switched using bit 0 of $D430 in the sub CPU memory.

katakana font

cg0.jpg (24.3 KiB) Visto 124 veces

hiragana font

CG1.jpg (25.57 KiB) Visto 124 veces

I don't think you need to use it. I've never used it either.

5) The INITIATE.ROM in the XM7 folder, where does it 'live' in Memory of an actual machine? I mean what addresses does it occupy?

INITIATE.ROM of XM7 is the initiator ROM that FM77AV allocates to $6000-$7FFF at boot time or reset.
The initiator ROM is the code that initializes the FM77AV hardware and performs the following processing.
- Initialize FM sound source, analog palette, etc.
- Subsystem mode setting
- Determining memory allocation
- Deployment of boot program
- Transfer control to system program

Once the role is completed, the initiator ROM becomes invalid.Users do not need to be aware of this.

[pser1]

@malikto999
current program XLOAD2 seems to be able to load an image (256x156@16 colours) in a bit more than 3 seconds on XM7
having checked the 'Add wait states ..' In fact it should be less because the program has various routines before reading data.
Currently the sectors are read into RAM and once we have a full Plane, this part is copied to some VRAM mapped region
This implies that main CPU will work @1,6MHz instead of 2MHz if I am not wrong ...
Another chance could be enabling the MMR just before sending data and disabling it immediately after ... Not sure if this could work (?)

The question is ... Will the process work any faster if once filled a Plane it is sent to the common area so that the Subsystem
can execute the stackblaster that would have been transferred previously, of course? Both CPU would work @2MHz that way.
I am not sure because I could be sending chunks of 64 bytes (2 rows at a time) but then I have to wait for the SUB to end
the copy process before sending the next 2 rows. Unless there is any chance to have two different buffers and we could
send One to the SUB, let it work and meanwhile fill the other buffer and then send that second one, filling the very first one
after doing so. Seems a bit tricky but maybe it could be done and save some time (?)

I am just trying to imagine as many ways as possible to send the data before entering the headaches of a compressor-decompressor system.
Any ideas would be highly appreciated
cheers!
pere

[pser1]

Hi,
thinking about the chance of having two buffers for the SUB to work with and keep the CPU speed to 2MHz, it
forces us to put both inside the common area. I was thinking in using the RAM inside the domain we could get from the SUB,
but this RAM must be accesed directly, so forcing MMR to be active and so 1,6MHz speed for main CPU

Having two buffers in the comon area will not help anyway because in order to write in one of them we must halt previously the SUB
so that seems to be another wrong choice to keep 2MHz CPU speed

Maybe the best would be sending 3 rows each time (96 bytes). Fortunately 156 rows is a friendly number divisible by 2 and 3!
I think that using YAMAUCHI command there are a bit more than 96 free bytes for data! Need to verify that.

There must be some way to do that damn file load faster!
I think someone said that there were some games programmed using the special 'dual 64 colours mode' and this implies
loading backgrounds using *six* planes, so 48.000 bytes and I am just tring to load less than half that (20.736 bytes)

cheers!
pere