marc.hull Posted June 7, 2014 Share Posted June 7, 2014 (edited) 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 June 7, 2014 by marc.hull Quote Link to comment Share on other sites More sharing options...
+mizapf Posted June 7, 2014 Share Posted June 7, 2014 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. Quote Link to comment Share on other sites More sharing options...
marc.hull Posted June 7, 2014 Share Posted June 7, 2014 This is known good. It's a zip file. RT-3-13.txt 2 Quote Link to comment Share on other sites More sharing options...
RobertLM78 Posted June 7, 2014 Author Share Posted June 7, 2014 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! as_robotron_2084.rpk Quote Link to comment Share on other sites More sharing options...
Asmusr Posted June 7, 2014 Share Posted June 7, 2014 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". Quote Link to comment Share on other sites More sharing options...
RobertLM78 Posted June 7, 2014 Author Share Posted June 7, 2014 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. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted June 7, 2014 Share Posted June 7, 2014 (edited) 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 June 7, 2014 by mizapf Quote Link to comment Share on other sites More sharing options...
+mizapf Posted June 7, 2014 Share Posted June 7, 2014 (edited) 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 June 7, 2014 by mizapf Quote Link to comment Share on other sites More sharing options...
+mizapf Posted June 8, 2014 Share Posted June 8, 2014 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 1 Quote Link to comment Share on other sites More sharing options...
RobertLM78 Posted June 8, 2014 Author Share Posted June 8, 2014 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). dmesg.txt Xorg.0.log.txt Quote Link to comment Share on other sites More sharing options...
marc.hull Posted June 8, 2014 Share Posted June 8, 2014 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. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted June 8, 2014 Share Posted June 8, 2014 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. Quote Link to comment Share on other sites More sharing options...
marc.hull Posted June 8, 2014 Share Posted June 8, 2014 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. Quote Link to comment Share on other sites More sharing options...
Asmusr Posted June 8, 2014 Share Posted June 8, 2014 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.com/host/0B68J8LwEkfDyTUdTQWlVN0VPaEU/index.html# Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted June 9, 2014 Share Posted June 9, 2014 I can get to Wave 9 fine in Js'99er and MESS, but Classic99 locks-up/crashes every now and then. Quote Link to comment Share on other sites More sharing options...
Tursi Posted June 28, 2015 Share Posted June 28, 2015 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. RoboTr2J.zip 4 Quote Link to comment Share on other sites More sharing options...
Plastik Posted June 28, 2015 Share Posted June 28, 2015 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 Quote Link to comment Share on other sites More sharing options...
Tursi Posted June 28, 2015 Share Posted June 28, 2015 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. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted January 2, 2017 Share Posted January 2, 2017 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. Quote Link to comment Share on other sites More sharing options...
8bitwidgets.com Posted September 4, 2023 Share Posted September 4, 2023 Seeing that someone has made a robotron for the TI-99/4a I make this coupler for 2600 joysticks. I imagine if any of you have the 2600 joystick adapter, this would be a viable option: PM me if you'd like one I have considered making a coupler for the original TI controllers as I do have a pair of them, but I wasn't sure if anyone would want them.. 4 Quote Link to comment Share on other sites More sharing options...
jrhodes Posted September 4, 2023 Share Posted September 4, 2023 6 hours ago, Caleb Garner said: I have considered making a coupler for the original TI controllers as I do have a pair of them, but I wasn't sure if anyone would want them.. Double the painsticks, double the pleasure? 3 Quote Link to comment Share on other sites More sharing options...
8bitwidgets.com Posted September 5, 2023 Share Posted September 5, 2023 (edited) 3 hours ago, jrhodes said: Double the painsticks, double the pleasure? lol hey man everyone has their thing. heh heh. i find them kind of charming.. though i do need to open mine up to service some to get them a bit more responsive. at some point i'll probably get the 2600 joystick adapter myself. Edited September 5, 2023 by Caleb Garner 3 Quote Link to comment Share on other sites More sharing options...
Retrospect Posted September 6, 2023 Share Posted September 6, 2023 On 9/5/2023 at 12:42 AM, jrhodes said: Double the painsticks, double the pleasure? carpal-carpal tunnel 4 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted September 6, 2023 Share Posted September 6, 2023 12 minutes ago, Retrospect said: carpal-carpal tunnel Double-mint twins gave me that. 2 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.