What's new
By:

Midway (Williams) Y unit (Z unit and T unit) Discussion, Serial Numbers etc

on the smash tv updates, I checked the actual rom files and the code still fits inside a 1mb rom. last address is at 1F945h so I've no idea why its complaining about not enough space. all this stuff is a real labour of love, grrrrr
 
mypinballs said:
on the smash tv updates, I checked the actual rom files and the code still fits inside a 1mb rom. last address is at 1F945h so I've no idea why its complaining about not enough space. all this stuff is a real labour of love, grrrrr
Click to expand...
I’ve realised now the issue, I have run out of space for 1meg roms like I thought before not by much but enough so it’s 2mb roms for the future

So I’m going to need to work out what changes are needed on real hardware for 2mb roms to work like on total carnage. I’m thinking probably a different u40 pal. Mame is going to need to be modified to but that was going to be needed for a new Rev version anyway

Not sure why midway didn’t just stick to 0000h for the rom start address on all games
 
As for MK2.
I'm having a real hard time linking the dynamic objects that i had assumed were used (link a bunch of OBJ into relocatable code that can be placed anywhere).
I saw @mypinballs had started the standard approach of linking normally. I took this route too.

Just posting my train of thought here. Ignore if you want :)

So let's look at the finished product that we have. After all, the ROM is just assembly copied in the right order, with the symbol tables from the OBJ's gone.
Link order matters, otherwise you will end up with instructions that cannot work, as they have limited "range". JUMP xxxx can only jump 0000-FFFF so if our target routine is outside this scope, we will never get there.

Using MAMEs debugger, the first object that got linked should be at 0xFF800000 in ROM.
1682673642994.png


This sure looks to me like the section "floor_code" in MKDISP.ASM: (code is slightly edited to allow it to match better to MAME's code view.

Code: 
floor_code
    move    @f_skew,a2,w        ; skew the ground ?
    jreq    kib9            ; no
    mmtm    sp,a3,a14
    move    @skew_scroll,a9,l
    move    *a9,a9,l
    move    @skew_oc,a10,l
    sub    a9,a10
    move    a10,@skew_oc,l        ; scroll "OFF CENTER" indicator !!

Great, so that's sorted if we put FLOORORG as the first section. But, what's next? Our MAP files tells us:
Code: 
FLOORORG   0    ff800000    000006f0
The next code object should be at +6f0 (In my build SHADORG section is there.) Production has this:

1682675477815.png


That does not look like SHADORG section at all.
Code: 
shadorg    callr    shad0
    move    @p2_obj,a8,l
    pull    b7

shad0    move    *a8(oflags2),a0,w
    btst    b_shadow,a0        ; shadow ?
    jreq    shad9            ; no

    move    *a8(oimg),a9,l        ; a9 ---> multipart ram
    move    *a8(oypos),a13,w
    move    *a8(oxpos),a0,w

Looking at the "CMP A14,A13" i cannot find this in the ASM files, followed by a SUB A10,A9, so i'm kind of stumped here.
Maybe we are missing some code? Let's dig thru more debugger production code from the bottom to top
FF8014F0 has shad3 from mkdisp.asm
FF801430 has shad1 from mkdisp.asm
FF801250 has shad2
FF801070 shad0
FF801000 has shadorg..

1682677703930.png


So what's this gobblygook from FF8006f0 then?
Something in between these sections, it's not empty and would be filled with FF since that's what the linker does.
Also, our floororg section does not 100% match with the original production code.
Ours: A205B0CE0501
Prod: A205D0EB0501

1682678692256.png


Kinda stumped right now..

Anyway, our next bit of code is maybe at FF8017B0 in the original? Doesn't match anything.

Just gonna match code now to get a feel for the general OBJ linkage.
FF80F2E0 "SETPPROC" UTIL.ASM
FF80DF40 "pinit" MPROC.ASM
FF804B60 "grav2" MKDISP.ASM
FF8049A0 "grav1" MKDISP.ASM
FF804720 ".if slowdma interrupt part? dmaq10?" in MKDISP.ASM
FF8045D0 "dma_interupt"
FF804000 "dclipl" , this is where the .text section of MKDISP.ASM should end up.. :)

FF800000 needs floororg
FF801000 needs shadorg
 
Last edited:
Rewrote parts of the CMD file but i end up with big gaps of FF and code mismatching versus the production rom.. maybe we do need relocatable code or something?

1682726988519.png


After the RETS at 800560 there is no proper code in my build for some reason.
This is gonna make me loose sleep :)

What's with the RAM difference:
orig ram: 105EBD0 (F_SKEW in ram..)
ours ram: 10ACF70 (off by 4E3A0)

Also, in /data there is two OUT objects that contain some interesting sections, which come from a (not-included) makefile..
Files ART.OUT and OART.OUT exist, and i'm not sure where they are built from.

RSCRN
DSCRN
SAVES
FRAMES
ASEQS
ABUFS
SYSRAM
CRAM
ROMIMG
FHOST
THOST
 
Last edited:
I failed C++ in college (because of illness, not due to lack of effort, but there was a total lack of effort...), I determined that I will never understand programming. if you have hardware issues I can help you, I fix arcade games, but this I cannot. LOL
 
I'll need a fine comb. Even with some fixed link order, our code does not align properly anymore since there were edits and commented/added routines/values.. etc.
I'm currently off by around 0x80 and an instruction takes 0x10. I've debugged the link order up to this:
Code: 
MKDISP.OBJ        /* IMAGE HANDLER            */
BAKGND.OBJ        /* background handlers */
BGNDPAL.OBJ        /* BACKGROUND TABLES */
BGNDTBL.OBJ        /* BACKGROUND PALETTES */
pall.obj         /* PALETTE ROUTINES        */
mproc.obj               /* MULTI-TASKER            */ /* fucks up ram area from ram.obj.. */
UTIL.OBJ        /* UTILITIES            */
MKINIT.OBJ        /* INITIALIZATION AND INTERRUPTS*/
ram.obj            /* MEMORY             */ /* .bss needs to be before mproc somehow */
/* Don't know below link order! */
/* stuff is misaligned because we edited it! */
MAIN.OBJ /* this looks to be in the right place? */

Also the .bss section for RAM.OBJ is in the wrong spot for some reason, it can be adjusted to match though. This is the reason the first instruction at FF800000 is wrong when compared to production. with ram.obj before mproc it's almost in the right spot at 0x105d0f0 versus 0x105ebd0.
 
Well, after some days of contemplating i've finally found that we need the unzip buffer at the start of RAM. (usect unzip..)
This makes the RAM.ASM .bss section align perfectly at its +0x8000 location, and there is no other way it could be made to line up like this.
Also the first instruction in FLOORORG section now matches and the first batch of instructions of the output rom file also matches up like it should

Code: 
    GROUP:
          {
        unzip: {}
           .BSS: {}
           .bss: {}
          } > SCRATCH
I'm still struggling with the alignment of the rest of the code. Black screens for now.
 
Tracing current code, we crash in ram.. debugged that.. Dirty fix from @mypinballs rc_bytei is not .bss. :) :) :)
From MK3, there's lots of nice stuff in DIAGHSTD.ASM, lucky we have this src.

To readers: There are routines / data that is missing in the mk2 source. These were found in the mk3 source leak from back in the day.
The windows source code contains a code drop with many asm files. MK3 builds upon MK2 _a lot_
This is the relevant part(s) for now..

Code: 
rc_byte
    movb    *a7,a0
    andi    byte_mask,a0
    rets

wc_byte
        .if tunit
    movb    a0,@wp_unlock    ;unlock cmos for a one shot write
        .endif

    movb    a0,*a7        ;write out the byte
    rets            ;and return

**************************************************************************
*                                                *
*      rc_bytei                                        *
*                                                *
*      read byte pointed to by a7...increment pointer to            *
*      "next" byte.                                        *
*                                                *
**************************************************************************
rc_bytei
    callr    rc_byte
    addi    c_byte_size,a7      ;words separate cmos bytes.
    move    a0,a0          ;return flags accordingly
    rets

rc_word
    mmtm    sp,a1,a7         ;use a1 to combine bytes
    callr    rc_bytei              ;get a byte
    move    a0,a1             ;save in a1
    andi    byte_mask,a1         ;mask only byte
    sll    8,a1             ;shift to high byte
    callr    rc_byte              ;get the 2nd byte
    andi    byte_mask,a0
    or    a1,a0             ;a0 has the word
    mmfm    sp,a1,a7       
    rets

rc_wordi
    callr    rc_word
    addi    c_word_size,a7      ;long separate cmos words.
    move    a0,a0          ;return flags accordingly
    rets

Also the duxpal?

Code: 
duxpal:
    .word     10
    .word    >0,>7c00,>6739,>1f,>35ad,>77a0,>741a,>3a0
    .word    >0,>10

Added it to git. More tomorrow. This brings new insight after 5+ days.. sigh. :)

Crash trace (DW 000h is not valid instruction, but it got CALLA'd to.)

Code: 
FF88BFF0: MMTM   SP,A7
FF88C010: MOVI   4h,A4
FF88C030: CLR    A1
FF88C040: CALLA  10B7F90h
010B7F90: DW     0000h
010B7FA0: DW     0000h
010B7FB0: DW     0000h
010B7FC0: DW     0000h
010B7FD0: DW     0000h
010B7FE0: DW     0000h
010B7FF0: DW     0000h
010B8000: DW     0000h
010B8010: DW     0000h
010B8020: DW     0000h
 
mypinballs said:
Yep, when you don't know what you don't know, you have to try things to get it moved forward and compiled!! i think without trying these things we would be still working out the linker issues. haha
Click to expand...
Fully agree, i wouldn't have gotten here at all if it didn't somewhat run or there was nothing to compare to. Now to work out why it crashes on the select screen, and why projectiles are not working.
 
Asure said:
Fully agree, i wouldn't have gotten here at all if it didn't somewhat run or there was nothing to compare to. Now to work out why it crashes on the select screen, and why projectiles are not working.
Click to expand...
This is certainly a fun project. I hope everyone following along is having a good time to, We are 'wild westing' all this shit!! haha

I need a texas rodeo hat!!
 
Game crashing is probably because it fails to create a process. This was changed in main.asm. audit_game_starts.
It uses the CREATE macro to do this.

I'm thinking we need to redo the DIAG* / CMOS stuff as this was the problem when we first started.
pid_secbust, secbust_proc.. on_hstd those things were all 'off' and causing compilation problems at first.

It seems audit stuff is also wrong or misconfigured, maybe we got a WIP build when they were changing this for, i'm not sure.
The game crashes wanting to audit the game start.
Might be related to the problem with continues in Smash TV / Carnage, as these probably also audit 'continues taken'. Not sure.

I need more time, but now i need to do real work and prepare for a weekend away, so progress will halt from here unless @mypinballs picks up from here ;)
 
Last edited:
It's not weekend yet. We're crashing here right now. Left is original product. Middle is the rebuild. Right is source.

1683039786873.png


Looking at the second window, our code takes a turn after the RETS at FFA55200. There's a MOVE there, and according to our .MAP file 010b84a0 is bad_aud (.bss) variable.
So the RETS is another routine that called the code below, and we enter at the part marked with ->. Then xor, then this bad cksum is stored.

Code: 
form_aud_cksum_and_store
    mmtm    sp,a1,a2               ;save a1!
    callr    form_aud_cksum
->    move    @bad_aud,a2,w               ;get the "fudge" word
    xor    a2,a1                   ;make cksum bad if audit is bad
    callr    store_aud_cksum
    mmfm    sp,a1,a2
    rets

Basic problem now is that it's crapping out on cmos writes when it wants to store 'games started' audit number.
I don't feel like breaking the game code so it just does no audits just to get it to run, i'd rather fix this properly.
On a side note, it seems almost all audit and adjustment code is missing writes to cmos, i cannot adjust and store volume, or coin settings, the number just does not change. and/or is not stored.
 
Last edited:
Asure said:
Game crashing is probably because it fails to create a process. This was changed in main.asm. audit_game_starts.
It uses the CREATE macro to do this.

I'm thinking we need to redo the DIAG* / CMOS stuff as this was the problem when we first started.
pid_secbust, secbust_proc.. on_hstd those things were all 'off' and causing compilation problems at first.

It seems audit stuff is also wrong or misconfigured, maybe we got a WIP build when they were changing this for, i'm not sure.
The game crashes wanting to audit the game start.
Might be related to the problem with continues in Smash TV / Carnage, as these probably also audit 'continues taken'. Not sure.

I need more time, but now i need to do real work and prepare for a weekend away, so progress will halt from here unless @mypinballs picks up from here ;)
Click to expand...
I will certainly take a look, I need to update my builds now we got passed the earlier issues. I have a fork of yours so will update form there

I need to fathom my 2mb smash tv build out first as I want to get the dip switch stuff nailed down first. Still don't understand why my build doesn't work. I was sure I had adjusted all the addressing correctly in the cmd file. Have we ever worked out why there is a ROM and ROM2 section? Why didn't they just put all the ROM2 group after the end of the main ROM group?? ROM2 in smashtv seems to just be the 'SHIT' section which suggests some sort of midway hack or bodge anyway.
 
Rom2 is for the .shit section, which i think is used with the toddview debugger (a hardware solution that we do not have + software tool which we do have.)
So that's not for production code, does not really matter to us.
 
Smash TV update.

2mb roms now work on mame and real hardware. No changes required for use on real hardware either :) So I now have loads of space for more features :)

And... DIP switches!! This is not the final use of the dip switches as is copied form Trog so will now make changes to suit our smash tv needs better.

IMG_7203.JPG
IMG_7209.JPG
 
You must log in or register to reply here.
Back
Top