PGM+MVS Homebrew

[Fluffy]

This is a quick pipeline test converting tilemaps data for IGS PGM and MVS, mainly to get a feeling for tilemap memory requirements. To try this you'll need to merge them with your own kov2.zip and ssideki2.zip, because these archives only contain my changed files. They are 7-zip archives wrapped in zip archives. It's probably easiest to set up a separate MAME so you don't mess up your main copy. Apparently the only way to launch games in MAME with invalid checksums is to use the command line.
The stick scrolls the map, buttons select the next or previous map.

The original graphics are from the old Amiga game "Disposable Hero", chosen for their size and colour depth (And because I was able to rip the maps with Maptapper). The original graphics are 16x16 tiles by 32 colours, with some tiles mirrored in Y. For PGM I'm combining 2x2 tiles to 32x32, and for NeoGeo I'm repacking the colours into 16 colour palettes.

So far I didn't have a chance to burn EPROMs to try either on original hardware. (Or find an MVS flash cartridge for sale.)

 

[iq_132]

Nice work! I'm looking forward to trying this out.
BTW, for what it's worth, FinalBurn Neo is much more accurate to the PGM's hardware than MAME at this point.
I've been adding findings from my hardware tests to it.
Just out of curiosity, are you planning some more full featured?

 

[Fluffy]

Right now this is only tech research/prototyping.

 

[Fluffy]

BTW, for what it's worth, FinalBurn Neo is much more accurate to the PGM's hardware than MAME at this point.

I just gave FinalBurn Neo a go, but it refuses to run games with invalid checksum... I could hack the source code, but I'm quite lazy about installing the dependencies.

 

[iq_132]

Sorry it took me so long to get back to this.
FinalBurn Neo will work with bad crcs, just make sure your rom sizes are right. You just have to click ok on the warning screen.
If you need a custom build made, let me know, I can post one that'll load whatever roms you want from raw files.

Also, I modified pgmfrog a little just based on what I think should work, but I couldn't get it to boot on my fluffy cart as it just gives a black screen for me.

 

[Fluffy]

I'll have a look - the first time I got it to work I inserted Trap instructions until I found where it stopped. I think one black screen problem was being stuck in the vblank handler.

 

[Fluffy]

Yeah, I've got the same result - black screen. The board is configured correctly, as the title of the game is added to the accounting info in the book keeping menu.
And a ddp3 rom I had at hand booted as well (with corrupted graphics).
I'll see if I can crack the problem. I wish there was an easy way to upload code to RAM without burning another EPROM... you could use the joypad inputs to upload data, but there are only the 4 counter outputs as output. Though I think I've got a FTDI chip somewhere that could be added to a cartridge.

The BIOS seems to contain some kind of host interface...

 

[iq_132]

Yeah, I've got the same result - black screen. The board is configured correctly, as the title of the game is added to the accounting info in the book keeping menu.
And a ddp3 rom I had at hand booted as well (with corrupted graphics).
I'll see if I can crack the problem. I wish there was an easy way to upload code to RAM without burning another EPROM... you could use the joypad inputs to upload data, but there are only the 4 counter outputs as output. Though I think I've got a FTDI chip somewhere that could be added to a cartridge.

The BIOS seems to contain some kind of host interface...

So this is something that @GC8TECH and I have worked on. I managed to get the PGM writing to my pc at a pretty good speed (115200 bps), but I couldn't get comms from the PC to the pgm working. I suspect there's circuitry that keeps coin counters and inputs from fluctuating too fast on the jamma edge/p3p4 output connector.

I've attached some photos of my test board, where the coin counters can be accessed that doesn't seem to have this limitation, my crappy little program's source code to receive writes from the pgm.
Also, here's my assembly code to write from the pgm to pc. I hope it works ok, I made some changes at some point to test and hope I didn't break this.

; 10 cycles per loop
; d7 is loops - 1
wait_loop   macro
wait_loop1\@
    dbra    D7, wait_loop1\@
    endm

; A0 source
; A1 end
; uses A2, D0,D1,D2, + D7 for wait loops
_write_to_pc
    lea.l   $c08006, A2
    move.w  #$0, D2
_write_to_pc_outer_loop
        ; ~173 cycles per bit

        ; write start bit
        move.w  #$0, (A2)   ; bit0 always 0

        ; slow down transfer
        ; #$8 for 115200
        moveq.l  #$9, D7
        wait_loop

        nop
        nop
        nop
        nop

        moveq.l  #$7, D0
        move.b  (A0)+, D1

_write_to_pc_inner_loop
            move.b  D1, D2
            lsr.b   #$1, D1
            and.b   #$1, D2
        not    D2    ;nop;    neg.b    D2
            move.w  D2, (A2)

            ; slow down transfer
            move.w  #$b, D7
            wait_loop

        dbra    D0, _write_to_pc_inner_loop

        ; slow down transfer
        moveq.l  #$0, D7
        wait_loop

        nop

        ; write stop bit
        move.w  #$ff, (A2)   ; bit0 always 1

        ; slow down transfer
        moveq.l  #$c, D7
        wait_loop

        nop
        nop
 
    cmpa.l    A0, A1
    bge.s   _write_to_pc_outer_loop

    rts

 

[Fluffy]

Here is a slightly newer build that should stop it freezing on a black screen - at the end of the VBlank handler I jump into the original BIOS vblank handler. So far I haven't been able to track down everything it does, but it seem to do something that allows the game to continue. I did notice that it writes into the "unknown" video register at 0xb04000, but so far I haven't had time to decode more of it.
This contains your DMA code, and I tried if initialising the sprite scaling table makes a difference. It doesn't, still no sprites on real hardware.

I suspect there's circuitry that keeps coin counters and inputs from fluctuating too fast on the jamma edge/p3p4 output connector.

Yeah, I've seen the joypad inputs often going through inductors to filter out spikes. Maybe you can do a similar trick to the coin counters and go directly to the gpio pin. I'll see if I can dig a bit more through the bios, maybe the host interface can be enabled without any extra hardware.

Update:
I found a few functions that may be related to a host interface, but they don't seem to be called from anywhere... There is actually a lot of code that looks valid but isn't used, though that may just be a standard library they're using that doesn't eliminate unused functions.

I wish I knew someone at IGS who had the SDK and documentation... And I wonder if there is a Chinese "Arcade Projects" style forum with more information.

 

[Fluffy]

On a slightly more positive note, I burned a program and tile rom for the Disposable demo, and it works on real hardware:

This is slightly newer then the build above as it includes some fixes I made to the frog demo as well.

 

[matt456]

Would love to help out experimenting more with this, I've never seen a reference to a "Disposable demo" though? I saw there was a simple Chaos demo for IGS PGM though. I'll try to see if that works.

 

[matt456]

Ignore me, I realise this is your work on Disposable Hero above anyway I'll spin up Chaos (PGM Demo) to see how that gets on.

 

[Fluffy]

The Disposable Hero demo doesn't do anything unknown. The scrolling code is a relatively simple VRAM update as you move through the map. To get around the problem with the vblank handler I'm calling into the BIOS vblank code. I can share the code if necessary, but the Frog Feast project is probably more useful.

This is my patched version of Frog Feast:
https://www.arcade-projects.com/threads/igs-pgm-frog-feast-on-real-hardware.17632/
This has the same IRQ problem as the Disposable Hero demo, and the sprites work only in Mame, but not on real hardware.
I'm trying to put this onto GitHub, but I want the history to reflect the original author correctly.

The open questions are:
- does the IRQ handler need to acknowledge the vblank irq somewhere?
- how do you get Sprites to work? I assume I'm missing some DMA setup.

Edit: I just had a look, looks like the Chaos demo was written by the same guy who did Frog Feast:
https://web.archive.org/web/20110101120041/http://arcadedev.emuvibes.com:80/

 

[matt456]

Thanks for the extra details, so far I have reversed in MAME the Z80 sound logic from oriental legend and wrote a simple sound driver which works on MAME but it fails on real hardware, something small I'm missing there no doubt. I'll take a look at this and see if we can nudge it along.

 

[Robbbert]

Just tried the ssideki2 one from the original post and it runs ok in MAME. There's just a small problem, there's 2 flickering squares near the left side. Apart from that it's fantastic.

 

[iq_132]

The Disposable Hero demo doesn't do anything unknown. The scrolling code is a relatively simple VRAM update as you move through the map. To get around the problem with the vblank handler I'm calling into the BIOS vblank code. I can share the code if necessary, but the Frog Feast project is probably more useful.

This is my patched version of Frog Feast:
https://www.arcade-projects.com/threads/igs-pgm-frog-feast-on-real-hardware.17632/
This has the same IRQ problem as the Disposable Hero demo, and the sprites work only in Mame, but not on real hardware.
I'm trying to put this onto GitHub, but I want the history to reflect the original author correctly.

The open questions are:
- does the IRQ handler need to acknowledge the vblank irq somewhere?
- how do you get Sprites to work? I assume I'm missing some DMA setup.

Edit: I just had a look, looks like the Chaos demo was written by the same guy who did Frog Feast:
https://web.archive.org/web/20110101120041/http://arcadedev.emuvibes.com:80/

I've done a bit more research on sprite buffering and interrupt ack's.
I wrote a test/demo of a simple snake game to test.

Here's a video running on real hardware with a sprite and game logic running from the vblank handler.

View: https://youtu.be/cAQ1gQctgL0


I've attached my source code (an Easy68k .x68 file) as well as a test binary.
This drops into a Happy 6-in-1 (replace the socketed program rom) cart and uses existing graphics data.

 

[matt456]

That's awesome! thanks IQ_132

 

[Fluffy]

From what I can see the main difference is the IRQ handler:

fn_irq6
;    clr.w    $700006    ; on-cart watchdog?
    move.w    inputs_current, inputs_previous
    move.w    addr_player_inputs, inputs_current
    addi.l    #$1, frame_counter

    move.w  #$0077, addr_video_flags    ; 1000 disable bg layer, pulse (0 << 3) for IRQ6 ack

    move.w    inputs_current, D0
    move.w    inputs_previous, D1

    move.w  #$107f, addr_video_flags    ; 1000 disable bg layer, pulse (1 << 3) for IRQ6 ack

    bsr        fn_game_logic

    ; no wait required for this pulse to register and start dma'ing the sprites?
    move.w  #$107e, addr_video_flags    ; 1000 for disable bg layer, pulse (0 << 0) for sprite buffer
    move.w  #$107f, addr_video_flags    ; 1000 disable bg layer, pulse (0 << 0) for sprite buffer

    andi.w    #$f0ff, SR
    rte

Or am I missing something?

 

[iq_132]

From what I can see the main difference is the IRQ handler:

fn_irq6
;    clr.w    $700006    ; on-cart watchdog?
    move.w    inputs_current, inputs_previous
    move.w    addr_player_inputs, inputs_current
    addi.l    #$1, frame_counter

    move.w  #$0077, addr_video_flags    ; 1000 disable bg layer, pulse (0 << 3) for IRQ6 ack

    move.w    inputs_current, D0
    move.w    inputs_previous, D1

    move.w  #$107f, addr_video_flags    ; 1000 disable bg layer, pulse (1 << 3) for IRQ6 ack

    bsr        fn_game_logic

    ; no wait required for this pulse to register and start dma'ing the sprites?
    move.w  #$107e, addr_video_flags    ; 1000 for disable bg layer, pulse (0 << 0) for sprite buffer
    move.w  #$107f, addr_video_flags    ; 1000 disable bg layer, pulse (0 << 0) for sprite buffer

    andi.w    #$f0ff, SR
    rte

Or am I missing something?

Yes, the irq ack flags have not previously been documented anywhere. It also demonstrates sprite setup & dma.

 

[Fluffy]

Ok, looks like I still have some bugs in my code, then... I'll have to find some time to get this to work, though.
I find the discovery of the bios handler quite exciting, though, it would allow to set debug options in the game without running the game. Have you found if there are any functions exposed from the bios that a game can use?