Thread in English for Fujitsu FM7

[pser1]

Último mensaje de la página anterior:

Morning everybody!
What a curious thing!
In the BASIC prompt if I use the arrows or any key, I have a delay.
But if I use a any key from the number pad, them I haven't got any delay.
Immediately repeat the pulsations.
Could we redefine those keys?

Código: Seleccionar todo

ReadKey   lbsr   Inkey                     ; read Keyboard
         clr   MovVert                  ; reset vertical move flag
         cmpa   #$1c      (¿#$36?)            ; received Right arrow? (Received 4 from numbpad)
         lbeq   GoRight                  ; yes, move right
         cmpa   #$1d      (¿#$34?)            ; received Left arrow? (Received 6 from numbpad)
         lbeq   GoLeft                  ; yes, move left
         cmpa   #$1e      (¿#$38?)            ; received Up arrow? (Received 8 from numbpad)
         lbeq   GoUp                     ; yes, move Up
         cmpa   #$1f      (¿#$32?)            ; received Down arrow? (Received 2 from numbpad)
         lbeq   GoDown                  ; yes, move Down
         anda   #%11011111               ; convert to uppercase
         cmpa   #'Q'                     ; is Q key?         
         bne   ReadKey                  ; no, read keyboard again

I'm not sure if this is the corrects codes of the numbers from the numberpad It's only a suggest.

Well, it is something to be tested. Would try to play with those codes, I will tell you the results

And another question:
Why the arrows scancode are $1c $1d $1e and $1f instead of $51$4f $4d $50?
Is it correct $40 $3E $3B and $43 for the numberpad key codes?
Ok! I know where it came from.
I suppose it's better take 32, 34, 36 and 38 because if you release the key automatically change to 35. While the logical code of the arrows is allwais the same although we relase the arrow key.
I'm not sure if it's clear with my beginer english.

Well, the problem (for me) is not your english, it is the lot of hexa codes you have talked about
Same than with the other comment, need to be tested, so till later ....
regards
pere

[pser1]

Back again,
I have tested the SHARK16 version, the one that doesn't save last pressed key to be used if none is received
Now it uses the numeric pad keys, codes like std numbers: $32-34-36-38
It works well, I hope this is not a feature added to XM7 that would not apply on the real hardware, anyone could confirm that point?
I don't know if I am seeing ghosts but looking at the screen carefully, it seems that moving horizontally
Brody has a few points where the movement is not continuous. Impossible to test for vertical moves because there are too few
steps to go.
In fact, testing version SHARK17, the one using old keypress when none is received, seems to show that same behaviour, at
certain places Brody's moves show a bit of a stop (almost unnoticeable)
I would appreciate your feedback on that question and tell me the method you'd prefer:
a) once Brody moves no need to keep pressing the arrow key, or
b) the contrary, you *must* keep the arrow keys pressed to move along
Now the .d77 contains three versions:
- SHARK16,the one that doesn't repeat move if you don't keep the key pressed (uses cursor keys)
- SHARK17 that just needs a keypress to move continuously (uses cursor keys and S to stop)
- SHARK16T is like SHARK16 but avoiding the delay before repeating same keypress (*** uses numeric keypad ***)
Thanks a lot
pere

SHARK16T.ZIP

(54.82 KiB) Descargado 62 veces

[pser1]

By the way, does Brody go one step each time the key is pressed?
It's a weak point of FM-7's keyboard, but it takes time to press down the key and begin key repeat.

Hi,
I would like to ask a question about that 'repeat' feature.
Most of us have our 'FM-7' in the box because of the extra space it needs (This is my case, at teast)
Playing with the Xm7 emulator, minter has discovered that the arrow keys show theat 'delay' behaviour, but
the numeric pad keys don't
Is it the same on the real hardware? I am afraid it would not be, but I should better ask!
If it were possible on the computer, I am sure most games would have been programmed to use those keys instead ...
Looking forward to your info about that point!
Thanks beforehand
pere

[malikto999]

Hi,
I would like to ask a question about that 'repeat' feature.
Most of us have our 'FM-7' in the box because of the extra space it needs (This is my case, at teast)
Playing with the Xm7 emulator, minter has discovered that the arrow keys show theat 'delay' behaviour, but
the numeric pad keys don't
Is it the same on the real hardware? I am afraid it would not be, but I should better ask!
If it were possible on the computer, I am sure most games would have been programmed to use those keys instead ...
Looking forward to your info about that point!
Thanks beforehand
pere

Unfortunately, it is a function unique to XM7, not real machine.
The state that keyboard setting "pseudo real time key scan" unchecked is the same behavior as the real machine.
This option seems to have been added to play old games comfortably.

The real time key scan was implemented since FM77AV.

My personal preference is to start moving by pressing 8,2,4,6 on the numeric keypad once and stop with 5 key.
It is because I am accustomed to it simply because many games use this key operation.

However, I think that any operability with this game is acceptable.
If a person who plays this game is not used to stopping by 5 key and feels stress such as unintentionally switching screens, you should avoid automatic continuous movement.

[minter]

The real time key scan was implemented since FM77AV.

You're right!!

I found this comment on "archive.org":

=== Controls ===
The directional keys are almost always numpad 4,6,2,8.
Many early games used the BREAK key as an action button (maps to ESC in XM7).

In early FM-7 games, the controls may seem weird. If you press a direction, the game will keep moving in that direction even after you let go. This is because the FM-8 and the FM-7 did not support real-time keyscan, so the computer can't detect key releases, only key presses. Simultaneous key presses aren't supported either (except for the BREAK key). As a workaround, many games used the numpad 5 key as a Stop button. FM77AV games don't have this problem.

On the other hand, the FM77AV had three(!) space keys, and some games use all of them, so you'll need to map the other two to something in the emulator (keys #57 and #58 on the XM7 keyboard map).

[malikto999]

I found this comment on "archive.org":

=== Controls ===
The directional keys are almost always numpad 4,6,2,8.
Many early games used the BREAK key as an action button (maps to ESC in XM7).

In early FM-7 games, the controls may seem weird. If you press a direction, the game will keep moving in that direction even after you let go. This is because the FM-8 and the FM-7 did not support real-time keyscan, so the computer can't detect key releases, only key presses. Simultaneous key presses aren't supported either (except for the BREAK key). As a workaround, many games used the numpad 5 key as a Stop button. FM77AV games don't have this problem.

On the other hand, the FM77AV had three(!) space keys, and some games use all of them, so you'll need to map the other two to something in the emulator (keys #57 and #58 on the XM7 keyboard map).

It is quite detailed. What is this document?

[jltursan]

You can find it in the Neokobe FM-7 compilation here: https://archive.org/details/Neo_Kobe_Fujitsu_FM-7_2016-02-25

[pser1]

Hi all,
I am going to ask for some help here.
Before stepping into events and showing conversations, moving from a location to another, and so on, I would prefer to
talk about the Brody's movement and how it is displayed by the Subsystem (I am not very happy with the results)
First of all, the main CPU is responsible for sending to the SubSystem (SS from now on) the mask and the sprite to be
shown (each 448 bytes, because it is 8x56) in chunks of 112 bytes.
Besides, the main CPU must reverse the mask/sprite when moving to the left because we have *only* the images to move
to the right. This parts seems to work well.
The SS must make transparent the part of previous position that will no more be occupied by Brody. To do so, it checks the
received block number and if it is the first one (#8) then it uses some received parameters to put zeros on both planes R-G
After that, the SS has to copy the 112 received bytes to the requested VRAM address.
Apparently this tasks are performed alright too.
The main CPU has a delay loop after sending each whole image (8 blocks of 112 bytes). This delay is smaller when moving to the
left to compensate for the extra time needed to reverse bytes.
If I compare the moves on the FM-7 against the moves on the Dragon, I see them much smoother on the Dragon. In the FM-7 it
seems that from time to time the size of the image varies just a bit ... and it is unfortunately noticiable.
In the Dragon I do all the data moves (screen update) when I detect the end of screen (vertical retrace) so we have quite a lot of
time to manage the Video RAM before the image on the screen is updated with the new data. Could this lack of synchronism
produce that strange Brody movement?
And if so, is there any way to get rid of that problem?
Sorry for writting a so long question/message
Thanks beforehand
pere

[pser1]

Sorry, I forgot to add the zip with the disk file and the source code ...
Here it goes
LOADM"SHARK24",,R
The arrow keys move Brody. The keypad numbers 2,4,6,8 too
Q quits the program. Any other key STOPS Brody!

cheers
pere

SHARK24.ZIP

(56.63 KiB) Descargado 70 veces

[malikto999]

Anyway, I'll upload a version I modified.
Two executable files 'shark' and 'sharkav' are included.

'Shark' has changed delay handling to use subsystem timers.
In addition to that, 'sharkav' has changed to synchronize with display status.

I will write a detailed explanation tomorrow.

[pser1]

Anyway, I'll upload a version I modified.
Two executable files 'shark' and 'sharkav' are included.
'Shark' has changed delay handling to use subsystem timers.
In addition to that, 'sharkav' has changed to synchronize with display status.
I will write a detailed explanation tomorrow.

Thanks a lot, Malik!
you are very kind!
I will study both versions in deep. Great chance to learn a bit more about that machine!
Have a nice weekend
pere

[pser1]

Anyway, I'll upload a version I modified.
Two executable files 'shark' and 'sharkav' are included.
'Shark' has changed delay handling to use subsystem timers.
In addition to that, 'sharkav' has changed to synchronize with display status.
I will write a detailed explanation tomorrow.

Hi,
I tried out both versions and didn't find much differences, I assume the reason is I was testing on XM7 emulating an FM-7
It is a nice way to unify the delays using the NMI, I like it.
I have not deleted/commented the code for the FM77AV despite it does nothing on the std FM-7
I have been working on the Subsystem functions and have unrolled three of them to make them run faster:
The "CleanA", trail eraser, the "ShowB" that shows Brody movements and the "PBytes" for the screen loading.

So, it seems that next step is going to be adding the 'event detector' so that conversations might be shown.
Some new parts to be added: Compressed text with its decompresser and the events for Location1.
Will come back to you when those pieces work well ... or if I get stuck on a problem!

Anyway I upload here version 26, so just LOADM"SHARK26",,R to test

cheers
pere

SHARK26 - unrolled some rutines in SS.zip

(57.52 KiB) Descargado 75 veces

[malikto999]

'Shark' has changed delay handling to use subsystem timers.
In addition to that, 'sharkav' has changed to synchronize with display status.

I will write a detailed explanation tomorrow.

On the subsystem, an NMI timer interrupt is always generated every 20msec.
And works ($D014-$D017) of the timer are updated each time an interrupt occurs.
You can use this work to wait at regular intervals regardless of machine performance or code load.
However, since NMI interrupt is every 20msec, it is not suitable for very detailed control such as synchronization of music performance.
In addition, since the work is accessed in the direct mode by the NMI interrupt, it is better to avoid changing the DP register by the user program.


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)

It should be able to draw without flickering if these are used, but honestly I also do not know the effect clearly.
Also, this I/O was added with FM77AV, but for some reason XM7 can also be used in FM-7 mode.
I do not know if it can be used even with the real FM-7. (Because the real machine owned by me is FM77AV40EX...)
As pser1 says, I think it is better not to use this.

[pser1]

Hello,
I had read somewhere that besides the internal sound generator, there was an add-on module for
creating sound that had a joystick connector too. It used one of the three internal expasion slots.
Not sure what the 'original' code was, but might be something like "MB22459" or the like ...
Does anybody know if this one would work on a standard FM-7?
I think that it was advertised for the FM-77 and the FM NEW-7
Thanks in advance
pere

[jltursan]

Yes to both, it's known as MB22459 or FM Sound Source and it works in the FM-7. The card provides a FM chip, the commonly used YM2203.
I still have to convert the demo tape to disk thanks to malikto999's tool

[pser1]

Hi,
getting info about pinout of video output of the FM-7, I have got two different infos:
Left image is from the FM-7 manual (FM-7 Specifications - 82HM-000030-1.pdf)
Right image is from web page
http://www.nausicaa.net/~lgreenf/fm7page.htm
Which one is correct (concerning pin 1)? Is it +12V or is it Video Clock?
cheers
pere

Pinout Compare.jpg (26.92 KiB) Visto 5302 veces

[jltursan]

The one from the manual. I've checked the output and measured an 1.6V/2Mhz signal, I've double-checked this as 1.6V is too low; but they're there without doubt...

I'm used to found +12V in most japanese machines; but it's true that the specs for pin 1 are +12V or video clock.