Thread in English for Fujitsu FM7

Avatar de Usuario
pser1
Mensajes: 1994
Registrado: 08 Dic 2012 18:34
Agradecido : 188 veces
Agradecimiento recibido: 161 veces

Re: Thread in English for Fujitsu FM7

Mensajepor pser1 » 06 Jul 2017 22:36

Último mensaje de la página anterior:

still another one:
How can I close a file inside an F-Basic program?
Using a basic that loads in sequence more that 15 files, gives an error like that
- File already open in line xxxx
thanks a lot
pere

malikto999
Mensajes: 53
Registrado: 09 Jun 2017 11:20
Agradecimiento recibido: 51 veces

Re: Thread in English for Fujitsu FM7

Mensajepor malikto999 » 07 Jul 2017 05:32

pser1 escribió:To download last version of ASM09WIN I have used this link, I hope it is OK
http://www.vector.co.jp/soft/winnt/prog/se513339.html

I have tried it and I found it difficult because it seems to force TABs to be nine (9) spaces whilst I am using just three (3)
So the text expands too far away by the right and comments get truncated falling to next line resulting in compiling errors.
Is there any way to change the TAB size?
Sorry I have not been able to find it -banghead

regards
pere


Sorry,the current version can not change the TAB size.
My coding style is to write label name 8 characters and margin 2 characters. So, the TAB size was fixed at 10.
I will consider free setting of the TAB size in the next upgrade.

malikto999
Mensajes: 53
Registrado: 09 Jun 2017 11:20
Agradecimiento recibido: 51 veces

Re: Thread in English for Fujitsu FM7

Mensajepor malikto999 » 07 Jul 2017 05:36

pser1 escribió:Hi,
another question ...
How can I detect a keypress on the BREAK key in assembler?
I am using the subroutine INKEY that uses the command $29 and every key returns its ASCII value except for the BREAK key
that is not detected ...
Could anyone tell me how could I detect that key?
thanks in advace
pere


The BREAK key is handled differently from other keys, so you can not get the key code.
It is processed by FIRQ interrupt.

To detect that the BREAK key has been pressed, use the following method.

1.Rewrite the FIRQ interrupt vector ($FFF6) to its own interrupt routine.
2.Judges whether it is an interrupt caused by the BREAK key in the interrupt routine.
Specifically, if bit1 of $FD04 is 0, it is the BREAK key interrupt.
If it is an interrupt other than the BREAK key, branch to the original interrupt vector.

I upload the sample code, please refer to it.
After executing the program on F-BASIC, please press the BREAK key several times.


By the way, even you may know, you can't get in real time that a key has been released in FM-7.
So in FM-7's game the character keeps moving even if you release move keys.
Among such keys, it is the BREAK key that you can get the state in real time only.
Adjuntos
sample.zip
(629 Bytes) Descargado 7 veces

malikto999
Mensajes: 53
Registrado: 09 Jun 2017 11:20
Agradecimiento recibido: 51 veces

Re: Thread in English for Fujitsu FM7

Mensajepor malikto999 » 07 Jul 2017 05:37

pser1 escribió:still another one:
How can I close a file inside an F-Basic program?
Using a basic that loads in sequence more that 15 files, gives an error like that
- File already open in line xxxx
thanks a lot
pere


Could you tell me the code that caused the error?
I want to know how to open a file.

Avatar de Usuario
pser1
Mensajes: 1994
Registrado: 08 Dic 2012 18:34
Agradecido : 188 veces
Agradecimiento recibido: 161 veces

Re: Thread in English for Fujitsu FM7

Mensajepor pser1 » 07 Jul 2017 15:53

malikto999 escribió:
pser1 escribió:still another one:
How can I close a file inside an F-Basic program?
Using a basic that loads in sequence more that 15 files, gives an error like that
- File already open in line xxxx
thanks a lot
pere

Could you tell me the code that caused the error?
I want to know how to open a file.

Hi,
for instance:

Código: Seleccionar todo

100 FOR I=1 TO15:READ A$:LOADM A$+".BIN":'THESE ARE DRAGON SCREEN IMAGES
110 ' DO SOMETHING (FOR INSTANCE DUPLICATE PIXELS AND SEND TO THE SUBSYSTEM)
120 NEXT: END
130 DATA FN1,FN2,FN3,FN4,FN5,FN6,FN7,FN8,FN9,FN10,FN11,FN12,FN13,FN14,FN15

cheers
pere

malikto999
Mensajes: 53
Registrado: 09 Jun 2017 11:20
Agradecimiento recibido: 51 veces

Re: Thread in English for Fujitsu FM7

Mensajepor malikto999 » 08 Jul 2017 07:58

pser1 escribió:Hi,
for instance:

Código: Seleccionar todo

100 FOR I=1 TO15:READ A$:LOADM A$+".BIN":'THESE ARE DRAGON SCREEN IMAGES
110 ' DO SOMETHING (FOR INSTANCE DUPLICATE PIXELS AND SEND TO THE SUBSYSTEM)
120 NEXT: END
130 DATA FN1,FN2,FN3,FN4,FN5,FN6,FN7,FN8,FN9,FN10,FN11,FN12,FN13,FN14,FN15

cheers
pere


I tried it on both the emulator and the real machine, but no errors occurred in my environment.
That error occurs when you execute the OPEN command with the same file number.
I am sorry, but I do not know why the error occurs with the LOADM command...

Avatar de Usuario
pser1
Mensajes: 1994
Registrado: 08 Dic 2012 18:34
Agradecido : 188 veces
Agradecimiento recibido: 161 veces

Re: Thread in English for Fujitsu FM7

Mensajepor pser1 » 08 Jul 2017 11:49

malikto999 escribió:I tried it on both the emulator and the real machine, but no errors occurred in my environment.
That error occurs when you execute the OPEN command with the same file number.
I am sorry, but I do not know why the error occurs with the LOADM command...

Hello Malik,
unfortunately I don't remember how did I start up the emulator disk system.
Maybe setting only one drive y too low number of files, not sure about that.
You are right, it works well even without the CLOSE basic command.
I am testing it on an XM7 emulation started with 2 drives, 15 files
I attach here the disk file (.D77) and the source file in assembler for the loader-expander
There are two basic programs, SCREENS uses the CLOSE command, but SCREENX doesn't
and both work flawlessly!
The disk contains 26 Dragon screens used along the Tiburon/Shark game
thanks a lot
pere
06-Screens.zip
(44.2 KiB) Descargado 11 veces


Ps By the way ... is there any way to call the LOADM command from within an assembler program?
We still do not have *any* technical info about the Disk Operating system, even in japanese would be a step forward -thumbup

Avatar de Usuario
pser1
Mensajes: 1994
Registrado: 08 Dic 2012 18:34
Agradecido : 188 veces
Agradecimiento recibido: 161 veces

Re: Thread in English for Fujitsu FM7

Mensajepor pser1 » 08 Jul 2017 13:31

malikto999 escribió:The BREAK key is handled differently from other keys, so you can not get the key code.
It is processed by FIRQ interrupt.
To detect that the BREAK key has been pressed, use the following method.
1.Rewrite the FIRQ interrupt vector ($FFF6) to its own interrupt routine.
2.Judges whether it is an interrupt caused by the BREAK key in the interrupt routine.
Specifically, if bit1 of $FD04 is 0, it is the BREAK key interrupt.
If it is an interrupt other than the BREAK key, branch to the original interrupt vector.
I upload the sample code, please refer to it.
After executing the program on F-BASIC, please press the BREAK key several times.
Thanks a bunch, simple and very clear example!
By the way, even you may know, you can't get in real time that a key has been released in FM-7.
So in FM-7's game the character keeps moving even if you release move keys.
Among such keys, it is the BREAK key that you can get the state in real time only.

Just a question about that.
I use command $29 (SubSystem function INKEY) setting flags on $fc83 to binary 00000011 so that it waits for a key
and besides it clears old keystroke, so calling this routine we should be able to know if the user is not pressing
the same key.
This command has the side effect of 'quitting' the user control loop at $c000, so I added a function call
to the Yamauchi $3F command with subcommand $93 (JSR $c000) to have control again over user commands.
Is there any other way to read the keyboard?
regards
pere

malikto999
Mensajes: 53
Registrado: 09 Jun 2017 11:20
Agradecimiento recibido: 51 veces

Re: Thread in English for Fujitsu FM7

Mensajepor malikto999 » 09 Jul 2017 02:53

pser1 escribió:Just a question about that.
I use command $29 (SubSystem function INKEY) setting flags on $fc83 to binary 00000011 so that it waits for a key
and besides it clears old keystroke, so calling this routine we should be able to know if the user is not pressing
the same key.
This command has the side effect of 'quitting' the user control loop at $c000, so I added a function call
to the Yamauchi $3F command with subcommand $93 (JSR $c000) to have control again over user commands.
Is there any other way to read the keyboard?
regards
pere


It can also be processed by IRQ interrupt on the main CPU side.
In the IRQ interrupt routine, get the interrupt source from $FD03. If it is a keyboard interrupt,read the keycode from $FD01.
However, it takes more effort than using subsystem commands, so I think your way is the best.

malikto999
Mensajes: 53
Registrado: 09 Jun 2017 11:20
Agradecimiento recibido: 51 veces

Re: Thread in English for Fujitsu FM7

Mensajepor malikto999 » 09 Jul 2017 03:39

pser1 escribió:Hello Malik,
unfortunately I don't remember how did I start up the emulator disk system.
Maybe setting only one drive y too low number of files, not sure about that.
You are right, it works well even without the CLOSE basic command.
I am testing it on an XM7 emulation started with 2 drives, 15 files
I attach here the disk file (.D77) and the source file in assembler for the loader-expander
There are two basic programs, SCREENS uses the CLOSE command, but SCREENX doesn't
and both work flawlessly!
The disk contains 26 Dragon screens used along the Tiburon/Shark game


I also made sure. It is a wonderful graphic! I can hardly wait for the day when this game is completed!


pser1 escribió:Ps By the way ... is there any way to call the LOADM command from within an assembler program?
We still do not have *any* technical info about the Disk Operating system, even in japanese would be a step forward -thumbup


Because the BIOS supports only I/O of the sector unit, Implementing the LOAD command yourself is very hard.
So, how about calling the LOAD routine in F-BASIC ROM?
It is easiest if you use it on the premise that no error occurs. (If an error occurs, control is transferred to F-BASIC.)

Just set the following works and call the LOAD entry (jsr $CF77).

$2F0 <- flag of loadm (0:LOADM other:LOAD)
$2F1-$2F2 <- loadm offset
$2EE <- execution flag after loading (0:no 3:execute)
$2EF <- 0
$2E6 <- drive number ($80:FDD0 $81:FDD1 $82:FDD2 $83:FDD3)
$2DD <- length of filename
$2DE-$2E5 <- filename

Avatar de Usuario
pser1
Mensajes: 1994
Registrado: 08 Dic 2012 18:34
Agradecido : 188 veces
Agradecimiento recibido: 161 veces

Re: Thread in English for Fujitsu FM7

Mensajepor pser1 » 09 Jul 2017 22:53

malikto999 escribió:I also made sure. It is a wonderful graphic! I can hardly wait for the day when this game is completed!

I think that this projet is going to be the *only* way to force us to learn more in deep about the FM-7. We cannot promise it will
be done in a certain period, but I am sure that this 'port' is going to be done!
Because the BIOS supports only I/O of the sector unit, Implementing the LOAD command yourself is very hard.
So, how about calling the LOAD routine in F-BASIC ROM?
It is easiest if you use it on the premise that no error occurs. (If an error occurs, control is transferred to F-BASIC.)
Just set the following works and call the LOAD entry (jsr $CF77).
$2F0 <- flag of loadm (0:LOADM other:LOAD)
$2F1-$2F2 <- loadm offset
$2EE <- execution flag after loading (0:no 3:execute)
$2EF <- 0
$2E6 <- drive number ($80:FDD0 $81:FDD1 $82:FDD2 $83:FDD3)
$2DD <- length of filename
$2DE-$2E5 <- filename

Alright, this reminds me what we do with the CoCo and Dragon, we build a string with the filename, extension and drive, for instance
"FileName.BIN:0" for the CoCo
"FileName.BIN:1" for the Dragon
And then we call the ROM rouitne inside the DOS
I assume that the file length should be calculated without header / trail bytes, so only the actual data bytes!
This procedure was a "must have" to go on the conversion/port phase.
I think that next step is going to be to show the main character (Brody) and get to move it around the screen
cotrolling the places where he is allowed to walk on.
Thanks a lot ... and be sure we will need you help/advice a thousand times more -nb
cheers
pere

Avatar de Usuario
pser1
Mensajes: 1994
Registrado: 08 Dic 2012 18:34
Agradecido : 188 veces
Agradecimiento recibido: 161 veces

Re: Thread in English for Fujitsu FM7

Mensajepor pser1 » 15 Jul 2017 17:10

malikto999 escribió:It is easiest if you use it on the premise that no error occurs. (If an error occurs, control is transferred to F-BASIC.)
Just set the following works and call the LOAD entry (jsr $CF77).
$2F0 <- flag of loadm (0:LOADM other:LOAD)
$2F1-$2F2 <- loadm offset
$2EE <- execution flag after loading (0:no 3:execute)
$2EF <- 0
$2E6 <- drive number ($80:FDD0 $81:FDD1 $82:FDD2 $83:FDD3)
$2DD <- length of filename
$2DE-$2E5 <- filename

I have added this method to load the files from the assembler program and works well, thanks a lot -drinks
The only problem I have is that I cannot spot the way the system calculates the byte at $2DD
It is not the number of clusters, nor the sectors number ...
Strangely, the executable program that is 908 bytes and the images that are 5003 bytes each have the same value there ($08)
Other files show a different number ...
Is it, maybe, some kind of CRC?
Could you explain us how should we proceed to calculate the value that has to be put at $2DD in order to load a file?
Thanks in advance
cheers
pere
Value2DD.jpg
Value2DD.jpg (154.42 KiB) Visto 206 veces

malikto999
Mensajes: 53
Registrado: 09 Jun 2017 11:20
Agradecimiento recibido: 51 veces

Re: Thread in English for Fujitsu FM7

Mensajepor malikto999 » 16 Jul 2017 02:18

pser1 escribió:I have added this method to load the files from the assembler program and works well, thanks a lot -drinks


I am glad to be able to help you,too.
Because there were few people who knew FM-7 around me, there was not very an opportunity to have such a talk.


pser1 escribió:The only problem I have is that I cannot spot the way the system calculates the byte at $2DD
It is not the number of clusters, nor the sectors number ...
Strangely, the executable program that is 908 bytes and the images that are 5003 bytes each have the same value there ($08)
Other files show a different number ...
Is it, maybe, some kind of CRC?
Could you explain us how should we proceed to calculate the value that has to be put at $2DD in order to load a file?
Thanks in advance
cheers
pere
Value2DD.jpg


It is not the size of the file.
Because it is length of the file name, it is OK if you set a number from 1 to 8.

Avatar de Usuario
pser1
Mensajes: 1994
Registrado: 08 Dic 2012 18:34
Agradecido : 188 veces
Agradecimiento recibido: 161 veces

Re: Thread in English for Fujitsu FM7

Mensajepor pser1 » 16 Jul 2017 16:28

malikto999 escribió:It is not the size of the file.
Because it is length of the file name, it is OK if you set a number from 1 to 8.

Incredible, I should have guessed! ... but asking is easier -thumbup
This makes a lot of sense unlike the whole filelength as I had wrongly understood!
Thanks a lot one more time
cheers
pere

Ps I see that this length includes the extension and the dot if it exists:
"L11X.bin" is exactly 8 bytes as "LOADIMGM"

malikto999
Mensajes: 53
Registrado: 09 Jun 2017 11:20
Agradecimiento recibido: 51 veces

Re: Thread in English for Fujitsu FM7

Mensajepor malikto999 » 17 Jul 2017 04:38

I explained how to use the LOAD routine in the F-BASIC ROM, but I will introduce how to call the BASIC command from the assembler more universally.
In this method, you can call all the BASIC commands from the assembler.

When F-BASIC searches for BASIC text in memory and finds an intermediate language code, it sets the next parameter address to $00D9,$00DA and then branches to the entry address of each command.
So if you prepare the parameter in your work address and set it to $00D9,$00DA and call the entry address of each command, you can execute the BASIC command from the assembler code.

In order to create parameters, I think that you can copy the memory contents by entering the BASIC program of the target command.

The start address of the BASIC text is stored in $0033,$0034.
Text is stored line by line in the following format.
+00-01 -> address of the next line (last line is $0000)
+02-03 -> line number
+04-nn -> intermediate language code + parameter data
+nn+1 -> $00

The list of intermediate language codes and entry addresses are put in the attached file.
In addition, since there is also a sample that calls the PLAY command from the assembler, please refer to that for concrete usage.
Adjuntos
sample.zip
(2.93 KiB) Descargado 6 veces

Avatar de Usuario
pser1
Mensajes: 1994
Registrado: 08 Dic 2012 18:34
Agradecido : 188 veces
Agradecimiento recibido: 161 veces

Re: Thread in English for Fujitsu FM7

Mensajepor pser1 » 18 Jul 2017 12:14

@malikto999
At this moment, I can control Brody's position and move him in the four directions after verifying that the move is allowed.

If I understood it right, now we should send the sprite to the 'G' plane so that the ones (1) show up as White and zeroes (0) do nothing.
Then inverting the bits (COMA) and sending that value to plane 'R' the old zeroes (0), now ones (1) show up as Black.
Asuming that's right, our problem is that Brody has some surrounding bits that *must* be transparent, so not overwritting the Background.

There we solve that with a double sprite, one is a mask with surroundings as '1' and rest as '0', so applying ANDA to the background
it 'deletes' the pixels that will be occupied by Brody, preserving the others.
Then we ADDA or ORA the other sprite that has the actual Brody, surrounded by zeros. The result is what we expected. No overwritting at all.
If I do that with Brody sprite, the surrounding zeros are converted to ones (1) and so they overprint the background with Black.

Do you know of any trick to move a sprite on the FM-7 without destroying the background? And, if possible, not doubling space (2 sprites)
Any hint or idea on that subject would be highly appreciated.
Thanks in advance
pere

EDIT. The size of Brody's sprites is 8x56 bytes = 448 bytes. We need three images to create the movement so 1.344 bytes
If we need to have a sprite for each plane (to save surroundings), then we would need 2.688 bytes out of the 4.096 at $c000-$cfff

malikto999
Mensajes: 53
Registrado: 09 Jun 2017 11:20
Agradecimiento recibido: 51 veces

Re: Thread in English for Fujitsu FM7

Mensajepor malikto999 » 19 Jul 2017 10:38

pser1 escribió:@malikto999
At this moment, I can control Brody's position and move him in the four directions after verifying that the move is allowed.

If I understood it right, now we should send the sprite to the 'G' plane so that the ones (1) show up as White and zeroes (0) do nothing.
Then inverting the bits (COMA) and sending that value to plane 'R' the old zeroes (0), now ones (1) show up as Black.
Asuming that's right, our problem is that Brody has some surrounding bits that *must* be transparent, so not overwritting the Background.

There we solve that with a double sprite, one is a mask with surroundings as '1' and rest as '0', so applying ANDA to the background
it 'deletes' the pixels that will be occupied by Brody, preserving the others.
Then we ADDA or ORA the other sprite that has the actual Brody, surrounded by zeros. The result is what we expected. No overwritting at all.
If I do that with Brody sprite, the surrounding zeros are converted to ones (1) and so they overprint the background with Black.

Do you know of any trick to move a sprite on the FM-7 without destroying the background? And, if possible, not doubling space (2 sprites)
Any hint or idea on that subject would be highly appreciated.
Thanks in advance
pere

EDIT. The size of Brody's sprites is 8x56 bytes = 448 bytes. We need three images to create the movement so 1.344 bytes
If we need to have a sprite for each plane (to save surroundings), then we would need 2.688 bytes out of the 4.096 at $c000-$cfff


I guess that the original (Dragon) Brody's pattern data has the following two types.
a) Brody's graphic data(the bit of the dot to be drawn white is 1, the bit of the dot to be drawn black or overlapped with the background is 0)
b) mask data for superimposing with the background (the bit of the dot for drawing Brody is 0, the bit of the dot to be superimposed on the background is 1)

Perhaps the original (Dragon) pattern drawing is applying AND for the background data and the mask data, and then applying OR for Brody's data,is not it?

These two types of data are also necessary for the method I propose. You can not superimpose with only the Brody's data.
If the above guess is correct, there should be original Brody's mask data.

First, write the mask data to the Red plane with bit reversal (COM).
Then it will be a graphic in which the background and the Brody's shadow (black) overlap.
It is not physically applying AND for the background Blue plane. By the color palette, it is displayed in black when the bit of the Red plane is 1.

Next, write the Brody's data to Green plane.
Depending on the color palette, if the bits of both Red and Green planes are 0, draw the background (Blue plane).
If the bit of the Red plane is 1 and the bit of the Green plane is 0, black is drawn. If the bit of Green plane is 1, draw white.

I'm sorry, do you understand this explanation for my poor English?
To erase him, you need to set both bits of the Red and Green planes to 0, you do not need to write on the Blue plane.


Volver a “Fujitsu FM7”

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 1 invitado