SFG05 Access

Pagina 3/5
1 | 2 | | 4 | 5

Van NYYRIKKI

Enlighted (5939)

afbeelding van NYYRIKKI

02-07-2014, 10:02

jr wrote:
NYYRIKKI wrote:

Really? This is first time I remember hearing that IM2 mode is used on MSX.

River Raid by Activision uses IM2.

Yes, actually I know that some software uses it, but I've not heard before that any MSX hardware would support IM2.

Van erwinmusik

Master (140)

afbeelding van erwinmusik

02-07-2014, 10:21

MBIOS of the SFG05 has three initalize modes:
1.0 IM1 for compatibility with SFG01
1.1 IM1
2.0 IM2 with full vectorized Interrupt support

Van erwinmusik

Master (140)

afbeelding van erwinmusik

02-07-2014, 20:37

As I wrote in another post, Yamaha has built great Hardware, all over the years.
The SFG05 was a giant step in this time ago and was.......
..... as Abdul confirmed, Yamaha isn´t able to write proper Software for it´s own Hardware. A current problem, they bought Steinberg years ago to get some cool programmers and Yamaha needed too many years to built the right Hardware for Nuendo: the Nuage System. It comes too late to beat Avid with their consoles. These Hardware is proubably the best in this Business, but they wasn´t able to got a just in time relationship of Software and Hardware.
By the way, a Problem of all japanese companies!
Tascam, Sony, Roland, Korg, Denon/Marantz... all of them are retarded, remember of the breakthrough developments these companies are done in the past!
I´m very tight with these Business and heard things You never believe....

Van erwinmusik

Master (140)

afbeelding van erwinmusik

03-07-2014, 23:39

YEAH!
I got my first RST38 HOOK

And I check inside Slot 3 the SFG05´s MIDI Status BIT 1 for incoming Data.
That works almost fine........

The mysterious BIT 5 is obvious mysterious!
Someone called it Frame Error, someone wrotes ??? at comment

hmmm, I dont know what this bit really does.

If I activate the lines to check this bit and RET if set, the code works almost as I expected.
If I deactivate the check lines, the Programm hangs if I played too much notes.

I simplify the Goteborg code for MIDI handling and built my own RST38 hook.

I uses the H.KEYI Hook, before the H.TIMI and I dont really know, if the SFG send an Interrupt or it´s only the VDP timer.
But, I´m not so far with my experience to realize everything, but happy to got a hook that comes back to my mainloop.

the Debugger of the BlueMSX does a very good work to achieve this point at all.
But in the case of fail without the BIT 5 check, the Debugger goes everywhere.....must to set many many breakpoints to figure this failure out. But not ready yet.
Maybe a stack overflow?

The Basics:
- have a code starts with bload "xxx.bin",R
- set the hook properly
- have a mainloop with some fine screenupdates of register and some Memory adresses
- see changing Register bits ... for a very short time Bit 5 goes ON and OFF
- only the hook goes inside the SFG05 and ask for MIDI and set my variables to show the bits
- check keybuffer and comes back to Basic with all nessecary resets and rebuilds of variables when I press "q"

But the mysterious bit 5 destroys all my checkups in my MIDI code.

Here is the part with MIDI check up, the basic of that I used succesfull in a small code only for MIDI THRU
Note: the buffer MIDIBUFF is only for static screen display and has no other meaning, no round robin etc...

; ************* INSIDE CODE *********************************
CHKSTAT: LD HL,MIDIBUFF
       
IMSLP: CALL INMD  ; call the INMD routine
       RET  C     ; if carry bit is set then exit
       LD   A,D   ; get the MIDI data
       BIT 7,A ; Statusbyte?
       RET Z  ; if Zero: RETURN
       LD   A,D   ; get the MIDI data again
       AND 10100000b ; other messages? Pressure or Control Change?
       CP  10100000b
       RET   Z  ; if YES: RETURN
       LD   A,D   ; get the MIDI data again
       AND 11000000b ; other messages? ChannelPressure + Pitch?
       CP  11000000b
       RET   Z  ; if YES: RETURN
       ; now, it´s obvious NOTE status byte
       LD   (HL),D   ; move to buffer
       CALL OPMD     ; Output first MIDI Byte
       INC  HL       ; point to next free area in buffer
       CALL INMD
       LD (HL),D
       CALL OPMD     ; Output second MIDI Byte
       INC HL
       CALL INMD
       LD (HL),D
       CALL OPMD     ; Output third MIDI Byte
       CAll Showstar ; set a variable for my screenupdate to show fully sent
       RET


;INPUT MIDI byte TO D-REG
;DATA:D                    X:A
;**************************************************************                    ;
INMD:  XOR D

       LD A,(MIDSTATR)       ;get status from Statusregister
      ;BIT 5,A                    
      ;RET  NZ  ;if bit 5 of status is set then Framing Error
      BIT 1,A                    ;
      RET Z ;if bit 1 of status is zero NO MIDI DATA
      LD A,(MIDDATR)          ;get MIDI data
      LD D,A                    ;move to D
      AND 0F0h                    ; if message=#F0..#FF  = System
      CP  0F0h                    ; then CANCEL
      JR  Z,INMD                    ; READ TIME
      AND  A                              ; NO ERROR
      RET
;**************************************************************
OPMD:      LD   A,(MIDSTATR)
           BIT  0,A
           JR   Z,OPMD
           LD   A,D
           LD  (MIDDATR),A
           RET

Someone out there with an idea? (@Abdul @NYRIKKI @grauw and so on...) Big smile

Van Grauw

Ascended (10604)

afbeelding van Grauw

04-07-2014, 00:38

Hey erwinmusik, I haven’t implemented SFG05 MIDI support in Synthesix yet because I need to repair my CX5MII first, so I can’t really tell from experience, but here’s a few thoughts…

Frame error means that not all bits were received properly. It shouldn’t occur normally I think, or at least not often. If it generates an interrupt that messes up your handling, maybe you can turn it off. The MIDI data byte should be ignored when this occurs. So your commented-out code seems correct.

However, when a framing error occurs, maybe you have to reset the error before it clears the interrupt…? If reading the status register doesn’t do it already.

What documentation do you use? I’m presuming the CX5M FAQ code example? (I see similarities.) And NYYRIKKI’s doc, but it just has high level description, no register bit documentation or anything. And then there’s the blueMSX romMapperSfg05.c / romMapperNet.c source code… Anything else?

Van Grauw

Ascended (10604)

afbeelding van Grauw

04-07-2014, 01:06

By the way, I wouldn’t put handling of the received bytes on the H.KEYI interrupt. Well, except maybe to do soft MIDI through. Just write it to a buffer, and return. Then, you can process the data in the main loop.

MIDI data transfer rate is 3125 bytes per second, or 52 bytes per 60Hz interrupt. This means we can use 1145 cycles (320 µs) to process a byte (5 lines). BIOS overhead for the H.KEYI hook is quite a lot (iirc around 600 cycles or so), if you also process the data there it likely becomes too slow.

In fact, maybe it is causing your problems, after all you say they occur only if you play too many notes at once. Although, I don’t know how framing errors are related to that. Maybe that 5th status bit is for buffer overflow in stead.

BIOS overhead is also why the SFG-05 BIOS offers an IM2-based mode of operation. In Synthesix I also use IM2 to avoid BIOS overhead. However, it shouldn’t be your primary concern, first you should make it work in IM1. If the code is correct it could lead to skipped bytes if it’s not fast enough or during VDP interrupt handling, but shouldn’t crash.

Van Grauw

Ascended (10604)

afbeelding van Grauw

04-07-2014, 04:06

Grauw wrote:

However, when a framing error occurs, maybe you have to reset the error before it clears the interrupt…? If reading the status register doesn’t do it already.

Looking through the MBIOS interrupt handlers in the debugger:

1. It reads the 3FF5 byte
2. It checks STAT bits 4 and 5
3. If either are set, it discards the byte and flags CMD bit 4

So, I suspect this CMD bit 4 resets the error.

Van Grauw

Ascended (10604)

afbeelding van Grauw

04-07-2014, 18:35

I had a late night disassembling the SFG-05 BIOS, and wrote the following article on the MSX Assembly Page with my findings:

Yamaha YM2148, SFG-05 MIDI interface

I still need to do some experimentation on the real machine once I’ve fixed my CX5MII, e.g. to figure out the function of command register bits 5 and 6, and if the buffer by chance can hold more than a single byte (I doubt it though). Also I want to make an actual implementation for it in Synthesix, and perhaps add some example code too.

But I think already it contains good information which was previously hard to find or unavailable, and hopefully no mistakes :).

Van Grauw

Ascended (10604)

afbeelding van Grauw

04-07-2014, 18:51

p.s. I wonder about the SFG-01. I have read that its MIDI support is limited because it does not support MIDI interrupts. Yet it also uses the YM2148, as per this photo. So, is the problem that the IRQ signal isn’t hooked up? Or is the hardware actually fully functional, and is it simply a BIOS software problem? Anyone knows? I don’t have one to test with myself unfortunately.

Van erwinmusik

Master (140)

afbeelding van erwinmusik

04-07-2014, 20:47

SFG-01......MIDI is full functional, as Abduls DMS1 shows formidable.
And the MBIOS 1.1 initialisation of the SFG05 says, IM1 compatibility to SFG01.
So as far as I understand, the MBIOS in the SFG01 has almost the functionality of the SFG05, except IM2 mode
I guess IM2 isn´t properly "wired" and something wrong with the MIDB Data block, where it is placed in the RAM. It overlaps with the, maybe later completed, disk BIOS. I can only guess, but the MSX development Team for the entire System cannot wait for only one manufactorer with his own additionals.

But as Abdul wrote, he does his program almost complete with DI.
Wether he uses his own timer or the timer of the modul. But without interupt handling for MIDI

This is what he wrote to the DMS-1 II

Quote:

Normally the system runs with interrupts disabled to ensure accurate playback, but while the system is waiting for the up-counter F9A2 to reach and cross the threshold value in F9A3, it enables interrupts so that any pending MSX system interrupts can be serviced. The NOP is there to ensure that any pending interrupts trigger a handler, as the Z80 datasheet suggested that if you put EI and DI back-to-back that there were circumstances where the interrupt handler may not trigger.

So basically it is waiting for a timed period to elapse, and while it is waiting, it uses this opportunity to allow any pending MSX interrupts to be serviced, as the rest of the time, the system runs with interrupts disabled.

Pagina 3/5
1 | 2 | | 4 | 5