ralphb

Thank you for your thoughts, but ... yes. You'll have ROM banks >6000->6FFF and as many RAM banks >7000->7FFF, and can bank switch both independently. So, you have both.

I thought you needed an external power supply? Or was that only if you attached it to the right of the Speech Synth?

Hah, thanks for the confirmation. I always wondered how much A one could draw from the cart port, especially since you cannot from the expansion port. When I connect the FG99 to my lab power supply, it seems to consume about 140 mA (cannot say if idling or thrashing , as the bus is unconnected).

Ah, I hadn't looked at the front page, so I guess that's fine. I think it's debatable if it makes sense to collect FG99 images here, as basically all cartridge dumps should work as-is (Minimem the only exception to the rule). It probably would make more sense to keep track of images that don't work (there are a few). This was different for the FR99, where some images needed special adaption. But I don't want to disrupt your great work here. If, however, you don't insist on downloads of individual games, you could keep the frontpage with a single link to a ZIP of all images and put that on WHTech.

Rich, would you be so kind to post your resulting BIN file? I'd like to compare to my output.

Thanks, Rich, for your explanation about the BR list. I didn't remember CASE, and I didn't know about the size difference between B and BR. This BR list is not preceded by CASE, but it may still be a branch list. The GPL code was written for my xga99, which is a bit more permissive than other GPL assemblers. The semicolon introduces a comment, like *, but doesn't have to start at the beginning of a line. Anyway, you converted the code exactly right. Note, however, that this is not the beginning of a program I want to write, but a test specifically for autostarting. What happens if you change >AA01 into >AAFF? Does it still work?

I inquired at Toshiba about the power consumption (Watt), but haven't heard back. If it works in a camera, it probably works in a cartridge as well, but still I'll let others try this out first.

I think my header is perfectly fine. I set 'AA' for cartridge and 'FF' for autostart, leave all powerup, menu, subprogram, DSRs etc. entries blank, and (auto-)start my code at >6013 as menu translator. This should work, but doesn't. For proof, let's look at some other autostarting image. This is the beginning of Fantastic Fractions: . 00000000: aaff 1f00 0000 0000 0000 0000 0000 0000 ................ 00000010: 0000 0040 3341 2754 0342 ac4c 7053 b643 [email protected]'T.B.LpS.C 00000020: 7442 c447 ab48 df4c 844f 5b56 024c 4a55 tB.G.H.L.O[V.LJU . Disassembled, it looks like this: . 6013: BR [email protected]>6033 40 33 6015: BR [email protected]>6127 41 27 6017: BR [email protected]>7403 54 03 6019: BR [email protected]>62AC 42 AC 601B: BR [email protected]>6C70 4C 70 601D: BR [email protected]>73B6 53 B6 601F: BR [email protected]>6374 43 74 6021: BR [email protected]>62C4 42 C4 6023: BR [email protected]>67AB 47 AB 6025: BR [email protected]>68DF 48 DF 6027: BR [email protected]>6C84 4C 84 6029: BR [email protected]>6F5B 4F 5B 602B: BR [email protected]>7602 56 02 602D: BR [email protected]>6C4A 4C 4A 602F: BR [email protected]>7587 55 87 6031: BR [email protected]>73DC 53 DC 6033: ST >01,[email protected]>2600 BE AF 26 00 01 ... . I don't get this. Why would you jump with BR instead of B, and why is there such a large list of jumps? I could be data, but doesn't look like it.

Wow, there's a lot going on here ... It seems you're mixing FR99 and FG99 ... Shouldn't you at least note whether an image is for the FR99 or the FG99? But why I'm posting: I noticed that the ZIP for the MiniMemory misses the configuration file to turn RAM on. Without this, you won't be able to load LBLA (but it might have been included in the dump). Just create a file phm3058G.CFG and put the letter "R" in there, nothing more. This will turn >7000->7FFF in all banks into RAM, which is separately switched.

I'm trying to create an auto-starting cartridge, or more precisely, a cart with a menu translator that is used to start the cart without a menu selection. MBX and SF titles do this. But when I run this program . * GROM auto start sample grom >6000 data >aaff data >0100 data 0 data 0 ;menu data 0, 0, 0, 0 byte 0, 0, 0 ;menu: ; data 0 ; data autostart ; byte 9 ; text 'AUTOSTART' autostart: all 42 ; >6013 fmt row 10 col 10 htext 'AUTOSTART' fend back 14 stop: b stop end . the TI crashes with a white screen (in MESS). When I add a proper menu, everything works. Is there anything special that programs have to do when running as a menu translator? Note that my program does not return, but keeps on running.

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.

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.

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?)

While you're at it, please do the 9995 as well.

Thanks Stuart, but why does the code start at >2A00? Shouldn't the ROM start at >6000, and the RAM with LBLA and LINES at >7000, with an additional GROM?

Never heard of such problems, and there are more than 200 FlashROMs in circulation. Where did you get yours?

Great, thanks to both of you!

Err, am I stupid, or couldn't you just load LBLA into MESS and dump the memory section? Except that there's no dump feature ... by default.

Sounds kind of good ... Let's discuss on Saturday. But maybe someone already has a binary ....?

Is there a binary (or even the source code) of the Line by Line Assembler available? I'm currently only aware of the WAV.

EDIT: Sorry, wrong forum, please delete (don't move)!

Have you checked out this thread? http://atariage.com/forums/topic/253095-flashrom-99-finalgrom-99-image-repository-3262017/ If that is not what you meant, please get back.

That's slick indeed, I didn't know this existed. But I wonder how much power the Wifi consumes -- after all, everything is powered by the TI cartridge port.

This took way longer than expected, but we finally solved the stability problems and are now ready to move on. These past weeks Eric (speccery) was kind enough to use his logic analyzer to analyze the faulty signals of the FinalGROM. And sure enough, he found two major issues. First, and this didn't involve the logic analyzer, I didn't connect AVcc on the microcontroller. I didn't read the datasheet and left AVcc unconnected, as I wasn't using AREF. Well, easy fix. Second, Eric found out that the control signals from the microcontroller to the CPLD weren't stable. During normal operation, they should remain constant, but he saw that occasionally at least one of them flopped to the other value for some nanoseconds. This would mess with the processing logic of the CPLD and thus yield arbitrary results. I think the most likely explanation for this is some kind of electrical problem, although we didn't find anything conclusive so far. But then the prototype #2 boards arrived, also two weeks late. Beside a new SRAM chip, the new boards also use a different voltage regulator. So I build a new cart, fixed AVcc, and voila: it is working flawlessly, having tested it for 8+ hours! So strictly speaking we didn't solve the problem, but it solved itself. Next, I'm going to design and send off the final board with the latest modifications to support the latest software updates. Once those boards are done, I'll send some out for general testing. But to speed things up, I'm also going to contact one or two testers for the current prototype board. I cannot thank Eric enough for his generous help in analyzing the FinalGROM. Without him, the FinalGROM wouldn't work today. And our collaboration was a lot of fun as well!

Yeah. I haven't tested it yet, but my idea was to have different bank switches for ROM and RAM sections.