FM77AV - learning how to program it (english thread)

[pser1]

I have taken a look at my ZX Spectrum +3 manual and yes, there is a "COPY" command .
Anyway, i have also seen a disk image with F-BASIC and it seems the commands are those (in abbreviated form):

DSKIN
DSKO
NAM
FIEL
LSE
RSE
DSK
CV
MKI
MKS
MKD
LO
DSKI

(offset 1700h on a F-BASIC D77 image)

Hello,
if you look at the Secoinsa manual for the FM-7 you will find a lot more commands with an explanation to use them properly!
Of course no COPY command at all there ...
cheers!

[jltursan]

Have you tried with L3 Disk Explorer?

It's probably the best disk image file explorer I know of...and sure, it supports F-BASIC...and even Flex or OS9 as well!

[pser1]

Have you tried with L3 Disk Explorer?
It's probably the best disk image file explorer I know of...and sure, it supports F-BASIC...and even Flex or OS9 as well!

Hello,
I have downloaded L3 Disk Explorer and despite selecting 2D, disk F-BASIC, when I open a .D77 the result is an error telling me that
there is an error in the FAT or DIR, I think ... Even renaming it to D88 same result.
cheers!
pere

EDIT: works well with 2 out of 3 disks I have tested. But all of them work flawlessly on XM7 ...

[jltursan]

There must be some subtle differences in the formats. If you can find the one that fully works, keep working on it...

[pser1]

Hello,
I have searched for a test program that fills the background with 64 colours and have sent it to the FM77AV
Much to my surprise, on the FM77AV the background is painted all colour white!
The foreground shows three coloured squares perfectly
Of course, on XM7 I can see the 64 colours on screen ...
Why is FM77AV showing a so different behaviour with respect to the XM7 emulator?
I attach here the source code of the program "TEST08C"
If anyone could give it a peek and could find the reason why it behaves different, I would appreciate any help to solve that problem
cheers!
pere

TEST08C.ZIP

(5.94 KiB) Descargado 18 veces

[pser1]

Hi,
I have just changed the order of two code lines.
The version that didn't work well was calling TYPE_B before calling SETPAL
Now it first calls SETPAL and then TYPE_B
The created disk autostarts correctly on XM7 but now it doesn't start on the FM77AV
I need to start with a normal FBASIC33 disk and then LOADM the executable from the other disk
Doing so the screen shows the 64 colours perfectly. I can move the foreground sprite with QAOP but when I press 'E'
the program doesn't exit on the FM77AV, but it does exit without issues on XM7
It seems that the computer emulation is not very exact, at least in my setup
cheers!
pere

[pser1]

Hi,
back again with more news ...
When 'E' is pressed the program exits but previous version didn't set TYPE_C before exiting. Now it does and works on XM7 and FM77AV
And suprisingly the disk I have created with this version, autostarts without issues on FM77AV
This could be related to the disk being not properly copied from PC to FM77AV. In fact I have used another disquet for maybe the one I was
using could have some problems ...
cheers!
pere

[jimbobaby]

Hello,
I have searched for a test program that fills the background with 64 colours and have sent it to the FM77AV
Much to my surprise, on the FM77AV the background is painted all colour white!
The foreground shows three coloured squares perfectly
Of course, on XM7 I can see the 64 colours on screen ...
Why is FM77AV showing a so different behaviour with respect to the XM7 emulator?
I attach here the source code of the program "TEST08C"
If anyone could give it a peek and could find the reason why it behaves different, I would appreciate any help to solve that problem
cheers!
pere
TEST08C.ZIP

Thank you.
It's very interesting. On XM7 and MUTSU, both fails to behave as real hw. And it's very nice to have a sample of it to reproduce

[jimbobaby]

Hi

I have programming questions, some may be related to FM77AV, some may be related to the 6809 CPU, and some related to my lack of knowledge in general

-I don't know the difference between IRQ and FIRQ
-I know the concept of "chaining" ISRs (i mean, put your own interrupt handler, see if it's for you, and if not, chain to the older handler), but i don't know how to check who has generated the IRQ/FIRQ (between, for example, keyboard event or an OPL timer).
It's specific for each device, or there is a common place to check?
-What happens if the interrupt handling is still doing it's thing and another IRQ trigger? The previous ISR get's interrupted? They get lost? You can control that disabling interrupts while on the ISR code?
-SUB cpu has no interrupt vectors on it's own? but i "know" that there are, at minimum, ACK's between main and sub, then how it works? are they handled by ROM code? (this is mostly curiosity... by now )
-According to my interpretation on the documentation there is a NMI on each vsync at SUB cpu, and a way to mask it (bit 7 of $D430). I don't understand any of them . I mean, a NMI by definition shouldn't be maskable , and two, how can i (if it's possible at all) put a handler in there to be called each frame?

I know those are mostly generic, and too much of a hassle to explain here, but any hint to documentation for any platform would be appreciated

Thank you!

[jltursan]

Undoubtely, these are questions for experts @pser1 and @malik999; but I least I can try to explain the difference between IRQ and FIRQ, still remember how both work...
It's just a matter of speed, both IRQ types work the same; but IRQ saves all registers before entering and restores all when exiting and so, wastes quite some time doing this. FIRQ (Fast-IRQ), only saves program counter and flags and thus it's faster; but you need to manually push/pop desired registers from the stack.

About interrupt handling, well, I can talk about the Z80, not sure how it works in the 6809. The Z80 automatically disables interrupts when servicing one, avoiding that another one triggers in the middle of the servicing routine. That means you need to manually enable them again before returning from the service.

And now, wild guessing about how both FM77AV CPUs are tied, I suppose that the "masking" of the SUB cpu is from the main CPU perspective, isn't it?. As you say, NMI interrupts are non-maskable. If the masking is within the SUB cpu itself...well, maybe the masking is externally achieved pulling high pin 2 of the 6809, this way I think no NMI will be triggered.

[jimbobaby]

It's just a matter of speed, both IRQ types work the same; but IRQ saves all registers before entering and restores all when exiting and so, wastes quite some time doing this. FIRQ (Fast-IRQ), only saves program counter and flags and thus it's faster; but you need to manually push/pop desired registers from the stack.

I see... so, the device itself should generate one or the other because of design reasons. Thank you

And now, wild guessing about how both FM77AV CPUs are tied, I suppose that the "masking" of the SUB cpu is from the main CPU perspective, isn't it?. As you say, NMI interrupts are non-maskable. If the masking is within the SUB cpu itself...well, maybe the masking is externally achieved pulling high pin 2 of the 6809, this way I think no NMI will be triggered.

That's the point, trying to use all the hw for our nefarious reasons . We'll see.

Offtopic (can't translate, sorry): he encontrao por aqui por retrowiki un mini tuto de asm 6809 con "poyos"[sic] hexadecimales por (quien sino) minter... que maravilla joer

[jltursan]

minter es asín...

[jimbobaby]

-I don't know the difference between IRQ and FIRQ
-I know the concept of "chaining" ISRs (i mean, put your own interrupt handler, see if it's for you, and if not, chain to the older handler), but i don't know how to check who has generated the IRQ/FIRQ (between, for example, keyboard event or an OPL timer).
It's specific for each device, or there is a common place to check?

Well, after jltursan response (thank you!), poyos en hexa , some reading and some tests i have mostly answered some of my own questions

Now i have some more

I have done IRQ testing (timer, keyb) and they work fine . But still can't work out the Yamaha (PSG) timers (that have both of them much better granularity).

I have studied the sakura sample (http://retrowiki.es/viewtopic.php?f=33& ... p200177001) (thanks malikto999!), and the Shounen Mike dissasembly (thanks Pere!), and have some doubts.

The FM7 family "abstracts" the programming of the audio chip with a layer in between ($FD15/$FD16), so you have another set of commands to talk to the Yamaha chip. You must send the $03 command and then you can use $02 to write and $01 to read. That's what it's documented. What is not documented (or i have not seen it yet on the docs that i have ) are the delays (only when writing) that both sample codes do (not much delay, 3 nops, between sending the writing command and writing the data). Why??

Also, i have seen another set of "unknown" commands used; on sakura, the $04 command (read status of the PSG timer?) and on Shounen the $09 command (for reading a data port of PSG?).

I'm interested because on my tests, i would create a handler for the IRQ ($FFF8), disable interrupts, program the timer (A or B, have tested both), enabled it (generating IRQ each tick), reenable interrupts, and then on the IRQ handler i would try to read PSG IRQ flag register (bits 2 and 3 of register $27), with the $03/$01 command sequence, to see the origin of the interrupt.
But doesn't work (generates the IRQ but fails afterward, still looking into it).

Also i tried to replicate what sakura's sample do (with the command $04) but again, to no luck...still

Can the PSG timers be used independent of the sound? (i mean, for another uses)

PD: After some tinkering, i can now run malikto999 c compiler native on my computer (no more virtual machines for development, yey!! )

[jimbobaby]

Also, i have seen another set of "unknown" commands used; on sakura, the $04 command (read status of the PSG timer?) and on Shounen the $09 command (for reading a data port of PSG?).

After some more reading, it seems that on the FM7 only the two lower bits are valid , but on the FM77AV there are the $04 and $09 commands. The former is for reading the status and the latter for reading the joystick port.

I'm interested because on my tests, i would create a handler for the IRQ ($FFF8), disable interrupts, program the timer (A or B, have tested both), enabled it (generating IRQ each tick), reenable interrupts, and then on the IRQ handler i would try to read PSG IRQ flag register (bits 2 and 3 of register $27), with the $03/$01 command sequence, to see the origin of the interrupt.
But doesn't work (generates the IRQ but fails afterward, still looking into it).

After more testing, IRQ gets generated, no problem, and go back to the program interrupted. But, for whatever reason (any of the stacks, maybe) when i do call printf, the program hangs (sometimes at half printing, sometimes after two or three calls). If i don't call printf it works fine until i do . That's even with a simple "RTI" at the IRQ handler, without any processing.

What i don't get is, if it's an IRQ (and not a FIRQ or any other mode), why some of them (standard timer and keystrokes) works just fine and the PSG generated somehow mess with the code? (i would assume stack issues, but i don't know enough).

[jimbobaby]

After more testing, IRQ gets generated, no problem, and go back to the program interrupted. But, for whatever reason (any of the stacks, maybe) when i do call printf, the program hangs (sometimes at half printing, sometimes after two or three calls). If i don't call printf it works fine until i do . That's even with a simple "RTI" at the IRQ handler, without any processing.

Ok, problem solved by now.

After more tests, cheking stacks and what not, i were seeing locks of SUB busy line (that's why printf hanged) .
Anyway, after cheking carefully again the Sakura sample, i was missing writing again on the IRQ handler the PSG register $27, then everything worked .

Also, i have read about the delays on writing on the Yamaha docs, so i suppose simply that emulators don't take it into account.

I'm trying now to understand the PSG timer's formulas, the scaling, the clocks... Right now i can get from 9 triggers/sec to 14.000 (a far cry from the maximum of 111.111, if i have done the math right), but to achieve 14.000 i have been forced to convert some routines to assembler .
Also,they seem to be logarithmic on the steppings, need to confirm, but i wasn't expecting that.

Step by step...

[pser1]

Hello,
let me come back to this thread to show you a small program I made to extract the fonts from the disk game "Shounen Mike"
I found a SUB function that is able to print chars on screen 8 bytes high and uses data included in the binary to print std european chars
But this same function accepts a pointer to $D800 instead to the other and so it can print another set of chars.
As the area $D800-$DFFF is in the SUB CPU area, I needed to map this area to main CPU RAM, so I thought I had done it.
In fact I stored $1D in $FD83 so that it is mapped to $3000-$3FFF
When I do execute the program, it does the work, but then it hangs, never returning to the Basic prompt
Clearly I have lost the practice to work with that FM77AV machine
I attach here the ASM source code and three screenshots showing the data I extracted anyway because pressing Hot Reset it breaks
the execution and I could SAVEM that area to disk to extract the binary file later and unassemble it to convert into fcb statements
for my Dragon so that it could show on screen (PMode4) those characters ...
As you will see, the Katakana ROM seems to contain data for chars not exactly japanese, don't you think so?
Any idea to solve the hanging problem will be very welcome!
cheers!
pere

ShounenMike FONTS.jpg (18.53 KiB) Visto 399 veces

Katakana ROM D800-D9FF.jpg (15.62 KiB) Visto 399 veces

Hiragana ROM DE00-DFFF.jpg (13.66 KiB) Visto 399 veces

KATAKANA.ZIP

(1.19 KiB) Descargado 18 veces