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

[Asure]

Does your 9.00 spawn proper enemiies or does it have gameplay issues like the one i built? I have some issues with invisible enemies, i wanted to build 8.00 production code later to check or fix up the first .word of the cobra/mutoid etc tables and see if this does something to make them visible.

 

[mypinballs]

I think there are still blank enemy issues but may be only certain ones as I see the tank guys later on etc

The problem is working out what the address changes are between the orig and new table outputs. I was comparing to see if I could find a link or a common offset etc but don’t see one yet

There is a lot of info comments wise on the load2 updates. It looks like if we could find the first release it would be the same as load1

 

[Asure]

Alternative would be to figure out how to update the LOD files to output the correct format.
I see it completely ignored the adres at the start for example, and also the spacing is off.

 

[mypinballs]

Alternative would be to figure out how to update the LOD files to output the correct format.
I see it completely ignored the adres at the start for example, and also the spacing is off.

Doesn’t seem like there’s much to change in the lod file other than the format I already did. They look mainly like a way to describe how to split up the wimp image files into the individual items and what palette to use . How load assigns the addresses for each part and the size is what we need to fathom out I think

 

[mypinballs]

Ok Stand BY!! I may have worked out this LOAD2 issue.. trying out some things at the mo....

More info to explain later ...

 

[Asure]

I tried several variants of /B /E /L and increased the base(in the .lod) to match it to where it started in the original file.
Two of the included LOD files start with ***> 3000000 as start adress, and ROBOY and ROBOY2 ***> 2000000.
I didn't do it methodically and i also didn't print the results like you are doing.

For me it kept adding the wrong number and not matching up to the .asm output from the backup that was made with the old load.exe
Also when i tried the banking / align switches i had to recalculate the base no. in the .lod file each time.
Like +100 + 100 + 100 became +80 + 40 + random + mismatch etc.

I did think about just creating new gfx romset +manual edit all the asm files from the IRW that gets built, but i had some issues at work that needed dealing with first, so i gave up for the moment lol.

(Total carnage source has CARNIMG.LRN to build gfx roms from IRW using SREC, see also CARNIMG.BAT.)

Looking at your notes indeed, we miss the monitor, its a single buggy line in my video, and the game freezes at that point.
Lucky that this is the first file created by load2 from the LOD..

View: https://www.youtube.com/watch?v=y1fOi09K728&t=147s

 

[mypinballs]

Ok, this is going to take some explaining!!! Here goes... Some serious hours put in here..

some bullet notes as follows:

- The *.lod file describes the image data and how each image created from wimp is split up in individual tiles/sprites etc
- The starting address for smashtv should be 0x02000000h
- My version 9 update set of files (built from v8 ) will run ok and not crash, but sprites are missing related to the *tbl files not being generated correctly.
- Luckily the backup folder contained original imgtbl.asm and bgndtbl.asm as found by @Asure, which give us a starting point for comparison on load2 generated files
- The img address value in the generated files should be a sequence number that increases by the size of each tile sprite logically.
- Load2 subtracts 0x02000000h from any starting addresss so to start at 00h at the beginning of the *.tbl file outputs, so we use ROBOY.lod, as this has 0x02000000h as the starting point.

The plan was to understand and find some common differences between what was outputted by the loadimg and load2 programs. After a lot of experimentation I found something. The gap for each sprite/tile etc is not the same on each output even after taking into account differing starting points. The answer is that load2 is creating an address jump 0.75 the size of the original output. This means that the addresses will become vastly out of position as the .lod file is processed and the files are created. (This maybe would not be an issue if we re-generated all the img rom files for load2 usage????, but this means for sure all new roms needed on real hardware and writing an img rom LRN file.)

Therefore an experiment was needed. Manually adjust some of the address values in the first .tbl file working out the correct size jump each time , recompile and in theory one of more of the missing sprites should reappear. Or part of a larger sprite should be ok and some of it still messed up etc. So I decided to manually adjust the first ten lines of the first .tbl file and see what happened.

The first file made form the .lod list in smash tv is the mutex.tbl file (and does indeed start at 00h when the above info is applied). This file is linked within mutoid.asm and creates the address info for the mutoid man sprite.

10 lines were recalculated and the modified mutexp.tbl file copied over, then the full code was cleaned and recompiled. new roms built and loaded in to mame. So now instead of a blank space where the mutoid man should be (as experienced before) , we should see some sort of functioning larger sprite, but maybe with some parts still messed up as we only edited the first bit of the .tbl file

And behold....

So the theory works! Now I need to probably write some sort of python script that can performs these alterations on a click of a button as manually editing each address and calculating the correct space is not trivial..

Happy though

 

[tiff_lee]

Keep up the great work @mypinballs and @Asure , this is like a 2 person show.
I'm sure i'm not the only one reading along with interest while unfortunately having nothing to contribute.

 

[Asure]

@mypinballs
Are you sure this is correct? I don't understand the decimal 0.75 increase you mention. Also my Windows calculator does not allow me to do decimal multiplcation of hex values
I wanted to make something in python to easy the job, but looking at IMGTBL.ASM i see a different factor, maybe different for TBL files?

IMGTBL.ASM
bldclt1 20D1A0
bldclt2 20D220 +80h
bldclt3 20D2C0 +A0h
bldclt4 20D500 +240h
bldclt5 20DC80 +780h

 

[Asure]

I started looking at more of the source/leaks over the days.
I really wanted to build Hangtime and WWF, but they require a special tool to process the ASM files. More on this later.

I looked at a lot of LOD files.
The later generation of LOD has many IHDR statements, as wel as PPP ZON ZOF stuff that's outlined in the doc (hangtime source repo)
Adding a random IHDR from the load2 sample folder gives me output very similar to what i would expect.
I used a small lod file for only mutexp.tbl:

IHDR SIZX:W,SIZY:W,ANIX:W,ANIY:W,SAG:L,CTRL:W,PAL:L

.word: word,word,word,word (sizex, size y, aniX,aniY)
.long (SAG: image address)
.word (dma2 ctrl, but we don't have this..)
.long (pallette name)

Now, the docs also state clearly:
IHDR SIZX:W,SIZY:W,SAG:L,ANIX:W,ANIY:W,CTRL:W,PAL:L is default (totally wrong for our intent and purpose)

So this leaves us with:
- We don't have DMA2 control flags i think (ours is DMA1)
- Where does it get the 0x6000 from
- What other stuff we need to do to get proper output/alignment? Are we using correct LOD file?

Maybe @mypinballs can see from this screenshot if the table is good enough? (my build root is a mess.)

 

[Asure]

I think i got it.

We need to turn of pixel packer(?) in LOD files:
(8 = no compression)

***> 2000000
IHDR SIZX:W,SIZY:W,ANIX:W,ANIY:W,SAG:L,PAL:B
ASM> MUTEXP.TBL
MUTEXP.IMG
PPP> 8

And we need to pad images to multiple of 4 bits using load2:

load2.exe yourlodfile /p /di /fi /t=c:\tmp /x /v

This _almost_ matches up with what we found in /backup, except the X size is off by one sometimes.
bldclt1: .word 3,4,0,-20 becomes .word 4,4,0,-20 for example. I don't know why.

But we don't care, we need the TBL not the ASM (search & replace .byte in the tbl files..)

It's 2.00 AM here, i need sleep. Bye!

 

[Asure]

Another day, more results.

Grunts broken. (i tried some manual adjustments, but it didn't improve much.)
Monitor works (second picture, the thing on the left, including the map screens etc).
Mutoid man is fine.
Suicide bomber guy is OK.
Not sure about COBRA.TBL, FLATFACE or GALAGAS.TBL

But we'll get there.

 

[mypinballs]

Now, the docs also state clearly:
IHDR SIZX:W,SIZY:W,SAG:L,ANIX:W,ANIY:W,CTRL:W,PAL:L is default (totally wrong for our intent and purpose)

Bingo, nice find, and I read though that doc a few times, but there it it in black and white lol as to why our files outputs were not formatted correctly and the sizing differences for the same images. Its is nice to see that load2 can be formatted to behave like loadimg (load1) then. I was thinking we were going to have to retrospectively update outputs to match, but this is way better

I will update my lod file later today and re-compile it all to see what I get. (I am currently looking at an indy jones Atari system 1 cocktail pcb)

The other game I would like to recompile is mk2, so I will look at this to after smash tv is sorted.

 

[Asure]

The grunts being broken might relate to the various revisions of the ROBO.LOD files we have, and that i'm not building the final revision of the code though.
I'm still working off the code in the root of the source (V5.00), but we have rev 8.00 in the /BACKUP folder which confused me at first.

 

[mypinballs]

The grunts being broken might relate to the various revisions of the ROBO.LOD files we have, and that i'm not building the final revision of the code though.
I'm still working off the code in the root of the source (V5.00), but we have rev 8.00 in the /BACKUP folder which confused me at first.

My version is based on v8 not v5 so I will let you know later

 

[mypinballs]

Also some thoughts on broken sprites etc (musings etc)

The lod file is sequential so if we get load2 working exactly my thought is the imgtbl and bgndtbl.asm outputs should match exactly. This way we know 100% the lod file updates are working correctly.

If we use bgndtbl.asm as a test point the first address in there is a good checking point because the bgndtbl is built last. ie it is at the end of the lod file.

From a quick check it is currently out by 3300H, which considering the amount of image sprites etc in the lod file is not that bad.

Looking though and comparing imgtabl.asm is also useful. It starts at the same point (meaning anything before the first reference of imgtbl is exactly matched) and the first point at which it deviates from the bkup file is at entry PHEAD8. The difference here is 1F80H. So maybe the img files in the archive are slightly different from what was used to make the image ROMs originally? OR we stilll have another config/option to fathom out.

 

[mypinballs]

The 'grunts' look like the sprite selection is either 1 sprite address ahead or behind where it should be. they look to be made from 2 sprites put together etc

 

[mypinballs]

From my build (v8 start) I see the same as you.I think we are good now in the list until the point I mentioned in the Imgtbl output

something weird going on here to with whatever these sprites should be

 

[mypinballs]

Also, I have my IHDR entry like this with the Pal set as long. It puts the entry on the same line as the other .long entry but still builds fine. No errors about .byte and having to manually update this first.

IHDR SIZX:W,SIZY:W,ANIX:W,ANIY:W,SAG:L,PAL:L

 

[mypinballs]

Ok,so a little experimentation with address numbering again

After some experimentation I added this line to my lod file before the flatface.tbl start to see if I could hack the address progression back to being correct again. I will try to explain the calc later on how I got to the address at this point.

***> 021B8420
D:\VIDEO\IMG\FLATFACE.IMG

I noted this change:

instead of this:

the GALAGAS.tbl (galaga 's) table file def is directly after the flatface one in the LOD file, so this appears to have fixed this table set to.

Now to work out the grunt stuff.

This is a bit of a hack though, it would be good still to understand what exactly is making the address pointers lose position from what we have in the bkup folder.