Jump to content

Photo

RoboTron

cart

43 replies to this topic

#26 marc.hull OFFLINE  

marc.hull

    Stargunner

  • 1,297 posts
  • Location:Oklahoma CIty.

Posted Fri Jun 6, 2014 6:38 PM

Is this a dump from one of the Competition Computers ROMs for Robotron or was it from a different prototype? There were several different prototypes out there, so maybe one of them is less buggy. I remember talking to Kyle about this one back in 1996 and he said the ROM he got initially was suffering from bit rot--and that he had to compare several to get an undamaged copy out of the mess. He got a lot of stuff from Atari back then--and I suspect his reconstruction was based on some partial source code access. . .


The dump came from Brian RB after he bought the proto from the author. He dumped the Roms and posted it. I don't think they were out there before that. They have always worked as far as I know.

Edited by marc.hull, Fri Jun 6, 2014 6:39 PM.


#27 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,401 posts
  • Location:Germany

Posted Sat Jun 7, 2014 5:59 AM

If we can identify one ROM set for Robotron as working, and we can prove that MESS is reproduceably failing where the real iron is working, then I can actually go for hunting that bug.

 

So if someone has a working real cartridge, can you check whether the recently posted as_robotron2084.rpk is identical to that one?

 

This makes it understandable why in MAME/MESS we always have hash codes with the ROMs (which rule out modified ROMs from working). The problem is that you have to make sure whether the copy of the ROM is indeed correct, just for cases like this. You cannot clearly find out whether you got a bad dump, or whether there is a bug in the emulation. For that reason, the ZIP cartridge format was favored to the RPK format, because we put the hash codes into the RPK (so everyone can change them at own will), while in the ZIP format, the hash codes are distributed with MESS. And this is why I (and some others) insist on keeping the RPK format, because this is more comfortable for homebrew software that is still evolving.



#28 marc.hull OFFLINE  

marc.hull

    Stargunner

  • 1,297 posts
  • Location:Oklahoma CIty.

Posted Sat Jun 7, 2014 8:11 AM

This is known good.  It's a zip file.

Attached Files



#29 RobertLM78 OFFLINE  

RobertLM78

    Stargunner

  • Topic Starter
  • 1,055 posts

Posted Sat Jun 7, 2014 12:47 PM

I attempted to make an rpk from the .bin file, but it's not working - I'm probably doing something wrong, just not sure what...

 

WARNING!  The attached .rpk does not work in this state!

 

Attached Files



#30 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,909 posts
  • Location:Denmark

Posted Sat Jun 7, 2014 1:13 PM

I attempted to make an rpk from the .bin file, but it's not working - I'm probably doing something wrong, just not sure what...

 

WARNING!  The attached .rpk does not work in this state!

 

Perhaps the banks are in the wrong order? Try changing  type="paged379i" to type="paged".



#31 RobertLM78 OFFLINE  

RobertLM78

    Stargunner

  • Topic Starter
  • 1,055 posts

Posted Sat Jun 7, 2014 1:25 PM

Well, no such luck with changing "paged379i" to "paged". 

 

I'm wondering though: the size of the first .bin (robotronc.bin) from the Michael's .rpk is 8192 bytes according to my PC.  In the softlist file, it says the size of that first ROM is >20FA or 8442 bytes - 250 bytes larger than what the PC reports as the size.  What I did for the size in the softlist for the new .rpk is add 500 bytes (since it's one ROM), hence the >41F4 on the new softlist file.  This all said though, I'm under the impression that the softlist file is not required, since the TIScramble cart only has a layout file, so my suspicion is that the problem lies in the layout file itself.



#32 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,401 posts
  • Location:Germany

Posted Sat Jun 7, 2014 5:19 PM

You should not trust the length value from the softlist, since it was autogenerated from the lengths of the bin files. I suppose the bin files are overdumped, i.e. they have trailing bytes. The correct length must be 8192. Last time when I uploaded the updated RPK, I used new bin files that I trimmed to 8192 on purpose.

 

The cartridge type is "paged".

 

The softlist is NOT required for RPKs. The softlist is the alternative cartridge handling method where you put the bin files into a ZIP file.

 

As for the cartridge, you either have to use two 8 K files with "paged" or one 16 K file with paged379i. However, the RPK is invalid because of a Zip file error. What zip utility did you use? I found that it requires version 0x0314 instead of 0x0014, and this is not accepted by MAME's unzip implementation.


Edited by mizapf, Sat Jun 7, 2014 5:44 PM.


#33 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,401 posts
  • Location:Germany

Posted Sat Jun 7, 2014 5:48 PM

This is known good.  It's a zip file.

 

Why did you upload it with "txt" suffix? This can be dangerous because servers or clients may be inclined to drop unprintable characters or change linefeed encoding. zip suffix should work.

 

How do you know the dump is good? Did you dump it by yourself?


Edited by mizapf, Sat Jun 7, 2014 5:49 PM.


#34 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,401 posts
  • Location:Germany

Posted Sat Jun 7, 2014 6:17 PM

Just checked: The Robotron RPK as provided by Robert can be fixed by splitting the file into two 8K parts and gluing them together in reverse order.

 

$ split -b8192 RT-3-13.bin
$ cat xab xaa > RT-3-13.bin


#35 RobertLM78 OFFLINE  

RobertLM78

    Stargunner

  • Topic Starter
  • 1,055 posts

Posted Sat Jun 7, 2014 8:05 PM

 

Just checked: The Robotron RPK as provided by Robert can be fixed by splitting the file into two 8K parts and gluing them together in reverse order.

$ split -b8192 RT-3-13.bin
$ cat xab xaa > RT-3-13.bin

Hmm, I wasn't able to get that to work. 

On the MESS crash: I tried the whtech rpk last night before a reboot.  Attached are the log and the dmesg output from immediately after restarting (the system crash like before, BTW).

Attached Files



#36 marc.hull OFFLINE  

marc.hull

    Stargunner

  • 1,297 posts
  • Location:Oklahoma CIty.

Posted Sun Jun 8, 2014 8:09 AM

 
Why did you upload it with "txt" suffix? This can be dangerous because servers or clients may be inclined to drop unprintable characters or change linefeed encoding. zip suffix should work.
 
How do you know the dump is good? Did you dump it by yourself?



This is a dump straight from the eprom I got from Bob. I suggest you do what Mike did and burn yourself a copy and play it on your console.

This dump is the same as the others floating around.

#37 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,401 posts
  • Location:Germany

Posted Sun Jun 8, 2014 10:02 AM

Should not sound as if I did not trust you, I just wanted to know that we can be absolutely sure. :-) In that case we can say all different ROMs are either buggy or beta releases.

 

Unfortunately I don't have a TI console anymore ... but actually, I could try to run it on my real Geneve. I just need to create cartridge files for the GPL loader.



#38 marc.hull OFFLINE  

marc.hull

    Stargunner

  • 1,297 posts
  • Location:Oklahoma CIty.

Posted Sun Jun 8, 2014 10:17 AM

I really doubt that there are any other dumps Mike. This cart had no. Known history until BRP dumped the proto he bought a while back. Not withstanding any hacks created later of which the other Mike made.

AFAIK the physical cart has always worked and only under emulation has there been issues. I suspect the code is exploiting HW behavior that is unexpected.

#39 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,909 posts
  • Location:Denmark

Posted Sun Jun 8, 2014 10:26 AM

It seems to work OK in my emulator (I added it to the Preloads menu). But I can't get any further than wave 3, so perhaps someone more skilled could try it?

 

https://googledrive....aEU/index.html#



#40 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • 4,160 posts

Posted Mon Jun 9, 2014 12:04 AM

I can get to Wave 9 fine in Js'99er and MESS, but Classic99 locks-up/crashes every now and then.

#41 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,329 posts
  • HarmlessLion
  • Location:BUR

Posted Sun Jun 28, 2015 4:45 AM

Just a necro thread to put this somewhere - this is my dual-joystick hack of the Robotron module from a few years back. No warranty, no guarantees that I didn't break anything or that the module I started with was not corrupt, but it appears to work.

Sadly I didn't seem to save any mod notes, I try to do that a lot more these days.

Attached Files



#42 Plastik OFFLINE  

Plastik

    Chopper Commander

  • 144 posts
  • The future is 8-bit
  • Location:New Jersey

Posted Sun Jun 28, 2015 9:45 AM

Just a necro thread to put this somewhere - this is my dual-joystick hack of the Robotron module from a few years back. No warranty, no guarantees that I didn't break anything or that the module I started with was not corrupt, but it appears to work.

Sadly I didn't seem to save any mod notes, I try to do that a lot more these days.

 

It breaks every few secs for me  :(



#43 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,329 posts
  • HarmlessLion
  • Location:BUR

Posted Sun Jun 28, 2015 12:08 PM

It breaks every few secs for me  :(


I can't really help you there. :/ I just booted it up in Classic99 here and got to Wave 7 without any problems.

#44 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,401 posts
  • Location:Germany

Posted Mon Jan 2, 2017 5:16 PM

I'm waking up this thread one more time. Robotron is currently the only game that shows problems in MAME that are not reported for real iron, so I kept this issue on my list. During the last days I spent some thoughts on that. But instead of identifying a possible glitch in MAME, it seems as if I successfully proved that Robotron is buggy. My current problem now is to sync that with the observation of other people. So let me explain what I found.

 

The basic problem of Robotron is that it does not properly handle interrupt masking. It implements several subroutines that are invoked by the video interrupt (via the hook at 83C4). In order to make use of these interrupt routines, it must enable interrupts by using LIMI 2; accordingly, there are some locations in the code where you can find this operation. When your interrupt routine is called via the hook, you can perform some operations, after which you have to return control to the master interrupt handler in the console at 0900. The golden rule is, as you may guess easily: Never allow interrupts inside the interrupt handler. The only exception is when you can push contexts on a stack so that you do not lose the values in the registers, in particular the return address. But we do not have something like that.

 

What I found is that while Robotron makes use of interrupts and implements own handlers, it also calls some common routines which enable interrupts. Thus, interrupts are enabled during interrupt handling as well. Theory says this will most certainly lead to a crash.

 

I did some tests in the last days and indeed found different kinds of issues, as expected. I considered trying this on my real Geneve, but Robotron uses an own key scanning routine which is not compatible with the Geneve, so I don't get past the entry screen.

 

Case 1: Crashing the master interrupt handler (MIH)

 

...
0AB0:     MOV  @>83C4,R12
0AB4:     JEQ  >0AB8
0AB6:     BL   *R12
0AB8:     CLR  R8
0ABA:     LWPI >83C0
0ABE:     RTWP

 

This is the end of the MIH. Line 0AB6 calls the custom handler, and this handler must return control to the MIH which returns control to the interrupted program at 0ABE.

 

What happens when the custom routine returns control with enabled interrupts? - In rare occasions, an interrupt may occur at address 0ABE, right before executing the RTWP. In that case, the original return vector will be overwritten. The symptoms are that sprites are set in motion but do not stop, a sound may be started without stopping, and the game is unresponsive to user operation.

 

Case 2: Crashing the custom interrupt handler

 

The following lines are taken from the code of Robotron. The computer was executing these lines when an interrupt occurred right after the operation at address 75A6.

 

75A4:     SWPB R1
75A6:     MOVB R1,@>8400   *** INT
75AA:     RT 

 

If things are done properly, we should expect the computer to return to address 75AA later. So when the execution was interrupted, the interrupt handler inside the console was called:

 

0900:     LIMI >0000
0904:     LWPI >83E0
0908:     CLR  R12
...
0AA8:     LWPI >83E0
0AAC:     AB   R14,@>8379
0AB0:     MOV  @>83C4,R12
0AB4:     JEQ  >0AB8
0AB6:     BL   *R12
0AB8:     CLR  R8
0ABA:     LWPI >83C0
0ABE:     RTWP     

 

The interrupt hook is set to 7FC6, thus the line at 0AB6 calls the custom interrupt handler at that address. I'll omit the lines of the handler here, some time later it arrives at this location:

 

643E:     MOV  R11,R13
...
644C:     LI   R0,>0300
6450:     LI   R1,>8320
6454:     LI   R2,>002A
6458:     BL   @>6094
645C:     CI   R3,>1F00
...
64AA:     B    *R13

 

The operation at address 6458 calls some subroutine at 6094; at 64AA is the return to the MIH. All this is still inside the handler, and the console interrupt handler has not finished yet.

 

6094:     LIMI >0000
6098:     MOVB @>61B4,@>8362
609E:     SWPB R0
60A0:     MOVB R0,@>8C02
60A4:     SWPB R0
60A6:     ORI  R0,>4000
60AA:     MOVB R0,@>8C02
60AE:     NOP
60B0:     NOP
60B2:     MOVB *R1,@>8C00
60B6:     LIMI >0002              *** INT
60BA:     LIMI >0000
60BE:     MOVB @>8362,@>8362
60C4:     JNE  >6094
60C6:     INC  R1
60C8:     INC  R0
60CA:     DEC  R2
60CC:     JNE  >60B2

 

As you can see, at 60B6, interrupts are enabled. In some very rare occasions, an interrupt may happen right here; when this happens, we are still handling the previous interrupt. So the return address from the interrupt will be 60BA, and the previous return address 75AA is lost. From now on, the interrupt handler calls itself and returns into itself. The game will crash.

 

One point here could be that the execution of the handler could be over before the next interrupt occurs. This is possible indeed, but these lines form a loop (60B2...60CC). If the loop is long enough, and it proved to be, the next interrupt will happen right in here.

 

**************************

 

Judging from the program code I would bet that Robotron is buggy and unstable. The emulation in MAME shows exactly that behavior; it takes some patience, however. Sometimes I can play right into wave 7 (don't know how to survive it, though), sometimes it fails at wave 3.

 

So I could easily close that case, but I don't feel comfortable ignoring the reports from some of you that the game runs without problems. I'm actually lost. Do we have different versions? Is there a fixed version? Do I have an error in the ROM banking? It writes at 7c22 (bank 1) and 7f2c (bank 0); I suppose that this is similar to all Atarisoft banking.

 

If anyone has a cartridge and is sure that the game does not crash, I'd like to get a dump. Otherwise this will remain an unsolvable issue.







Also tagged with one or more of these keywords: cart

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users