Mess updates thread

[+mizapf]

Ninerpedia is always good as a reference

http://www.ninerpedia.org/index.php?title=MESS_multicart_system

 

The points that Rasmus cited are still valid, just the comment taken from an old version. The upper 2K is a merge of the previous two 2K blocks. I tried to set up a theory how the GROM could be organised internally (also from tmc0430.cpp):

 

 

  baddr = m_address & 0x07ff;
  bank = (m_address & 0x1800)>>11;
  m_buffer = 0;
  if (bank == 0) m_buffer |= m_memptr[baddr];
  if (bank & 1) m_buffer  |= m_memptr[baddr | 0x0800];
  if (bank & 2) m_buffer  |= m_memptr[baddr | 0x1000];
...

 

So you see that if bank==3, two banks are activated at the same time.

[ralphb]

That's pretty werid, but also cool that you and/or someone was able to re-engineer that. Thanks for posting that snippet!

[+mizapf]

There must be some logic behind all weirdness.

[ralphb]

Yes, surely, sometimes weird code translates into a very simple circuit. Bank switching is one such example, albeit a very simple one.

[+mizapf]

The above snippet just reflects my theory about GROMs, so it is not a guarantee that real GROMs work this way. Similarly, the state machine that I implemented is also just a theory about the behavior, which provides a good match with the observable behavior.

 

The easiest way to combine outputs from sub-circuits is to wire them together. Someone told me (you or Jens-Eike) that GROMs are PMOS circuits, which means that there is a "pull-up" network: For a 0 value, the output transistors have high impedance, and the combined output is pulled down to 0 by a resistor. If only one output of the sub-circuits is 1, this pulls up the output to 1. This is obviously a "wired-or" circuit, and this could be the explanation why we have a "superposition" of the values at locations addr+0x800 and addr+0x1000. The OR operations should represent in code what seems to be happening in the real circuit.

 

I do not know much about decapping, but I guess you can only find the memory with its bit mask, but you will not find out (at least with reasonable efforts) how the logic works.

Edited January 6, 2017 by mizapf

[Tursi]

I do not know much about decapping, but I guess you can only find the memory with its bit mask, but you will not find out (at least with reasonable efforts) how the logic works.

 

Actually decapping reveals a great deal about how the logic works in most cases -- decapping the 6502 was how they came up with the circuit diagram to reproduce it. I don't personally understand HOW, but they can read most of the circuit.

[+mizapf]

Hmmm ... maybe I should give those guys some GROMs after all?

[+Ksarul]

That might not be a bad idea, Michael. A definitive map of exactly what an original GROM is doing would be highly educational. We have the nice analyses that you and Tursi did from outside the chip (and from somewhat different directions), but decapping will give absolute certainty of what the expected behavior should be.

[RickyDean]

That might not be a bad idea, Michael. A definitive map of exactly what an original GROM is doing would be highly educational. We have the nice analyses that you and Tursi did from outside the chip (and from somewhat different directions), but decapping will give absolute certainty of what the expected behavior should be.

Could you decap a couple of PAL's too, That would possibly help in some replacement /development areas?

[ralphb]

I'm currently looking at MBX games such as Sewermania. There are two versions on WHTech, mbx_sewermania and mb_sewermania -- the former has C and G, but the latter only has G.

 

As far as I know MBX games had 1 KB of RAM at >6C00->6FFF, and used a different banking scheme with "reversed" banks. Yet, when I look at the layout.xml, I only find <pcb type="standard">.

 

How does MESS know that it has to treat this game differently? (And if mbx_sewermania is the original game, who hacked mb_sewermania, and why?)

[+mizapf]

Those with the mbx prefix are MBX games, while mb is just Milton Bradley, not requiring the MBX console. I don't know whether and in what way it was modified; this was one major incentive to clean up the complete cartridge set, looking for original versions with verified CRC checksum. You find these versions in the ZIP collection only, however. And unfortunately, not all cartridges had checksums.

 

That is, yes, it is pretty likely that in the RPKs there are lots of hacked cartridges.

Edited April 5, 2017 by mizapf

[RXB]

RXB (XB ROMs) are hacked using the GK XB ROMs. Only 2 bytes are changed so the Editor can use the new routines COPY and MOVE, also PRINT sections of lines.

[ralphb]

As far as I know, the MBX version also worked on a plain console without MBX device, so why mb_sewerman?

 

But I looked at the new sewerman.zip, and it doesn't match either one. The ZIP also doesn't have a layout.xml, so I assume the bank switching circuitry to be used is hard-coded inside MAME and cannot be changed for ZIP files.

 

Ninerpedia lists <pcb type="mbx">, which the other carts don't use, so both must be hacked to use the standard cart format -- and thus probably use 32K.

 

I guess I answered all my questions.

[+mizapf]

I guess I answered all my questions.

 

I'm not sure.

 

The sewerman.zip does not contain a layout.xml because in the newer, standard ZIP definition, the layout is included in MAME for all cartridges (except homebrew). What you were looking for is this (part of ti99_cart.xml):

 

 

<software name="sewerman">
  <description>Sewermania</description>
  <year>1983</year>
  <publisher>Milton Bradley</publisher>
  <info name="serial" value="PHM 3150"/>
  <info name="usage" value="MBX console optional" />
  <part name="cart" interface="ti99_cart">
   <feature name="pcb" value="mbx" />
   <dataarea name="grom" size="0x4000">
    <rom name="phm3150g3.bin" size="0x1800" crc="dc888809" sha1="3e8bb9767767ad965d4ea8f0315fd1d70aa61534" offset="0x0000" />
    <rom name="phm3150g4.bin" size="0x1800" crc="c9942ea7" sha1="7d085ce8b1c455362e8b96d384404d4c4f03b1d6" offset="0x2000" />
   </dataarea>
   <dataarea name="rom" size="0x4000">
    <rom name="phm3150c.bin" size="0x4000" crc="962aca6f" sha1="2266d883869df89592f9a32da2c7760204298dc5" offset="0x0000" />
   </dataarea>
   <dataarea name="ram" size="1024"></dataarea>
  </part>
</software>

 

The bank switching for MBX cartridges is described in gromport.cpp:

 

 

Cartridge type: MBX
    GROM: up to 5 GROMs (sockets for a maximum of 3 GROMs, but may be stacked)
    ROM: up to 16 KiB (in up to 2 banks of 8KiB each)
    RAM: 1022 B (0x6c00-0x6ffd, overrides ROM in that area)
    ROM mapper: 6ffe
    TODO: Some MBX cartridges assume the presence of the MBX system
    (special user interface box with speech input/output)
    and will not run without it. This MBX hardware is not emulated yet.
    GROM space
    6000     77ff   8000     97ff   a000     b7ff   c000     d7ff   e000     f7ff
    |== GROM3 ==|...|== GROM4 ==|...|== GROM5 ==|...|== GROM6 ==|...|== GROM7 ==|
    ROM space
    6000             6c00    7000                 7fff
    |                 |       |                     |
    |                 |       |===== ROM bank 0 ====|       6ffe = 00
    |                 |= RAM =|                     |
    |=== ROM bank 0 ==|       |===== ROM bank 1 ====|       6ffe = 01
                              |                     |
                              |===== ROM bank 2 ====|       6ffe = 02
                              |                     |
                              |===== ROM bank 3 ====|       6ffe = 03
    The 16K ROM is composed of four 4K banks, which can be selected by writing
    the bank number to address 6ffe. This also affects the RAM so that the
    bank number is stored in RAM and may also be read from there.
    The mapper does not decode the LSB of the address, so it changes value when
    a write operation is done on 6FFF. Since the TI console always writes the
    odd byte first, then the even byte, the last byte written is actually 6FFE.
    ROM bank 0 (ROM area 0000-0fff) is always visible in the space 6000-6bff.
    RAM is implemented by two 1024x4 RAM circuits and is not affected by banking.

[ralphb]

Thanks, it's good to see this spelled out.

 

What I was getting at: I was wondering why both Sewermania.rpk didn't work on the FinalGROM. Looking at the dumps, they don't use the MBX cart type, but standard. Hence, there is no RAM on the cart when running in MESS, so they must use the 32K -- which I just confirmed.

 

I'm not too familiar with the ZIPs yet, but I think it's good idea to have verified dumps.