PGM+MVS Homebrew

[iq_132]

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?

Yes, there's a lookup table in the bios for a few functions (two of which I could figure out), otherwise the bios isn't really used.
The code below is enough to actually replace the entire bios (with Caveats, oriental legends requires the ram be initialized properly, asic games expect the bios to be going through the start-up process while they hash check and write the decryption code for the 68k rom, etc).

START:
ORG $0

dc.l $820000 ; sp
dc.l init_function ; initial pc

ORG $70
dc.l irq4

ORG $78
dc.l irq6

ORG $100

init_function
move.l $100004, -(A7)
rts

irq4
move.l $100070, -(A7)
rts

irq6
move.l $100078, -(A7)
rts

ORG $230
dc.b 'V0001', 0, 0, 0 ; first word read and used by the cart's rom for... something?
dc.l coin_handler ; 238
dc.l unknown_23c ; 23c
dc.l unknown_240 ; 240
dc.l test_mode_button ; 244
dc.l unknown_248 ; 248

coin_handler
unknown_23c
unknown_240
test_mode_button
unknown_248
rts

END START

Using this init in the bios is good enough (at least in an emulator) to get every game except Oriental Legend working/launching fine.

init_function
; count frames until we hit 760 - this is the standard boot time for a pgm game (with the splash enabled)
;  this fixes killing blade plus, ddp2,
    moveq.l    #$0, D0
    lea.l    $b07000, A0 ; scanline counter
frame_counter_1
    cmpi.w    #$e0, (A0) ; check current scanline
    bne.s    frame_counter_1
frame_counter_2
    cmpi.w    #$e1, (A0) ; check current scanline
    bne.s    frame_counter_2
    addq.l    #$1, D0
    cmpi.w    #$2f8, D0 ;760 frames
    bne.s    frame_counter_1

    move.l    $100004, -(A7)
    rts

 

[Fluffy]

Ah, ok, I found those functions but not the table...
The first three seem to be function dispatchers of some kind:
0x238

void handle_host_func(int func_index,int func_argument)
{
  switch(func_index) {
  case 0:
    FUN_000056a8();
    break;
  case 1:
    FUN_00005722();
    break;
  case 2:
    FUN_000057a4();
    break;
  case 3:
    FUN_0000581c();
    break;
  case 4:
    FUN_00005862();
    break;
  case 5:
    FUN_000058a8(func_argument);
    break;
  case 6:
    FUN_000058f6(func_argument);
    break;
  default:
    print_at(10,10,"HOST FUN ERROR %d",func_index);
    do {
                    /* WARNING: Do nothing block with infinite loop */
    } while( true );
  }
  return;
}

0x23c:

void handle_host_func2(int func_index,int func_arg)

{
  switch(func_index) {
  case 0:
    FUN_00001764(func_arg);
    break;
  case 1:
    FUN_0000182a(func_arg);
    break;
  case 2:
    FUN_000017f6(func_arg,0);
    break;
  case 3:
    FUN_000018fc();
    break;
  default:
    print_at(10,10,"HOST FUN ERROR %d",func_index);
    do {
                    /* WARNING: Do nothing block with infinite loop */
    } while( true );
  }
  return;
}

0x240:

void host_sound(int func_index,int func_arg1,int func_arg2)

{
  uint in_D0;
  
  if (func_index == 0) {
    FUN_0000d982(0x10,in_D0 & 0xffffff00 | func_arg1 & 0xffU,0xff);
  }
  else if (func_index == 1) {
    FUN_0000d7d2(0,func_arg1 & 0xffff,(uint)func_arg2 >> 0x18,0);
  }
  else {
    print_at(10,10,"HOST SOUND ERROR %d",func_index);
  }
  return;
}

Of course, these are Ghidra decompilations, so take with a grain of salt. And I haven't gone further than this, as I didn't know if they are used before I didn't look too deep into what they're doing.

 

[Fluffy]

This is a small test to use the text layer on PGM to scroll the level. This helps with art that uses 8x8 or 16x16 tiles to not inflate the tileset too much, though comes with a handful of disadvantages: You would have to use sprites (or the 32x32 layer?) for HUD graphics, you can use only 16 colour palettes, the BIOS eats up a majority of the tileset space (user tiles start at 0xc000), and there is no linescrolling.

 

[iq_132]

@Fluffy

Here's a list of tests that would be nice to have (and I plan on working on)
- Can we change the scroll registers and do raster effects for the FG (Char/text) layer [this would let us have a HUD]?
- Sprite zooming isn't 100% figured out - the register at $b04000 seems to be related?
- How many sprites per line are allowed?
- I know the interrupts are configured by the cartridge, but does IRQ4 get triggered more than once or just on line 218?
- does bit 0 of the attr word for the character and background ram do anything? It's odd that it doesn't? - it doesn't appear to do anything even w/hardware tests
- does bit 15 of each palette word do anything? On Neo-geo this is a "dark" bit?
- sprite DMA timing (how long does it take, and is the main ram inaccessible when it's dma'ing?)
- what do the unknown bits in the $b0e000 register do? Any sort of IRQ4 control?
- which interrupts are enabled when a cart is NOT inserted - none - the bios doesn't get interrupts???
- verify $700006 is a watchdog - appears to be more interrupt acks?

 

[Fluffy]

I was actually wondering about raster effects myself. If the display runs in sync with the clock signal that is on the cartridge port it would be possible to control this with a timer, similar to NeoGeo.
I'll have to see if I can get communication to work, so I can test code without burning another EPROM. I found a blue pill board in my stuff and the inputs should be 5V tolerant, maybe I can get something based on that to work.

 

[iq_132]

Here are my current mame sources documenting the hardware. I haven't run any further tests for my list above, but I did find that $700006 seems to be another irq4 ack?

 

[Robbbert]

I don't mean to be rude, but... is that code supposed to be working?

Firstly I tried it with HBMAME and although it compiled all I got was a black screen.

HBMAME code is a bit old, so I tried it on current MAME. Unfortunately, same result.

Any suggestions?

 

[iq_132]

I don't mean to be rude, but... is that code supposed to be working?

Firstly I tried it with HBMAME and although it compiled all I got was a black screen.

HBMAME code is a bit old, so I tried it on current MAME. Unfortunately, same result.

Any suggestions?

I didn't realize I hadn't replied to you. Here are my current sources. If this doesn't work for you, try clearing your NVRAM and a clean build, shoot me a message on discord?

 

[Robbbert]

Thanks, tested with current mame (a little after 0.254), appears to be working. I only tested a few titles but didn't see anything bad.
I looked at the Discord but you're offline and greyed out.
Next is to try this code with hbmame - if it doesn't work then that's my problem.

 

[Robbbert]

Just to keep you in the loop, I was able to get it going in HBMAME. The commercial games and their hacks worked, however the 3 homebrews failed to show the sprites. Frog Feast was entirely black (I think it uses sprites for everything). I reverted back to the old code.

In MAME, while letting one of the commercial games run its attract mode for a while, a joystick suddenly appeared in the middle of the screen, it moved left and right then disappeared.

So I guess there might be an address masking issue in the sprites code? You would obviously know better than I. Anyway up to you if you want to do anything further.

 

[Fluffy]

The frog feast doesn't work on original hardware, either, and the disposable demo doesn't have sprites. I'll have a look if I can get the mame build working as well.

 

[iq_132]

The demo/homebrew sprite issue absolutely mirrors hardware. What commercial game were you testing?

 

[Fluffy]

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.

One thing I'd like to try is a variation of this:
https://github.com/wickerwaka/PicoROM
... for the 27c322 footprint.

With a 16 bit data bus you'll only have enough address lines for a few kB of memory, but that may be enough for some boot code and a shared memory buffer. Or use two PicoROM.
Right now I'm incredibly busy, though.

 

[iq_132]

That's really interesting! I could find a few use cases for this.