The FinalGROM 99

[Omega-TI]

You mentioned cheat codes....

 

One of the things I always liked about PC games BITD was 'GOD MODE' in games like Duke Nuke 3D and Doom as well as the way the games were designed to allow user designed levels. The cheat codes allowed poor players like myself to practice and the open design gave those games life far past what would have been a normal lifespan.

[chrisdad]

I for sure am sold on this. Put me down for one as well!! Here is a crazy idea.. Not sure if it is even possible. is it possible to build in a sort of High Score program that saves and loads scores via a floppy disk? One floppy disk for all games kind of thing. I figure it would only work with a game that save a high score in game, such as Donkey Kong. I don't know all the implications, it sounds near impossible to me. Super cool though if accomplished. You were knowledgeable enough to create this and the prior cart, I don't under estimate your ability a bit..Figured I would throw that insanely complicated sounding option out there. Maybe a button on the cart that could grab the score from within the game and save it type of thing would work as well..

Edited January 17, 2017 by chrisdad

[Asmusr]

With 512K it might not be so important, but would it be possible for software copied to the TI 32K to swap another image from the SD card into ROM space?

[weirdocollector]

Please, add me to the wanting list

[ralphb]

You’ve used the XC95144XL, but there’s also the XC95288XL. Pin compatible, but double macrocells.

If you need a beta tester, I have a Xilinx cable and IMPACT installed.

 

Yes, the 95288 would be the end of the Fahnenstange. I started with the 9572, but when I put both GROM and image loading in it would no longer fit the 9572. The 95144 still complains about things, so maybe I'll have to move pin assignments a little. But the 95288 costs €18, whereas the 95144 can be had for €7, so I'll stick to the 95144.

 

The CF7+, by the way, uses a tiny 9536, but then I guess there's some additional logic in the piggy-back adapter.

 

I'll send you a test board when they're ready.

 

So there is a possibility of groms 0,1 & 2 being able to be replaced?

 

I haven't tried it yet. I'd also need some extra logic to tell console GROMs from cart GROMs. But someone said that the GRAM Kracker "just shouts louder", so maybe it could work.

 

Ralph seems to mention that he opened the door for new apps to start using GRAM, I see endless possibilities.

 

Thanks again for that suggestion, but to be honest, this has probably the least priority for me. Which doesn't mean I won't try it, but if I have to choose between some additional features then GRAM will be out.

 

Ralph is your menu a rom image or a grom? If the former it won't even load on a 2.2 console right?

 

Ouch, now that's a very good point! So far, it is ROM, and I'm not really in the mood to rewrite the menu in GPL. Let's see if a wrapper will do.

 

It's possible to add the folder support from FinalGROM99 to FlashROM99? That would be beyond cool

 

In theory yes, but it depends if it fits into the 8515, which has barely any bytes left. I'll try further down the road, but it's pretty unlikely. The FinalGROM has 16K of program space, whereas the FlashROM only had 8K.

 

Here is a crazy idea.. Not sure if it is even possible. is it possible to build in a sort of High Score program that saves and loads scores via a floppy disk?

 

No, sorry. That'd be too much magic.

 

With 512K it might not be so important, but would it be possible for software copied to the TI 32K to swap another image from the SD card into ROM space?

 

It's not that easy. The main problem is that you'd have to distinguish bank switches from image selection. Selecting a game is alternating writes to >6000 and >70xy, where xy is a byte of the filename you want to load. Right now bank switches and image selection are temporally separate, but if image selection must always be active then you have a conflict with games like Pac-Man that use absurd addresses for bank selection, which would be interpreted as image selection.

[Asmusr]

It's not that easy. The main problem is that you'd have to distinguish bank switches from image selection. Selecting a game is alternating writes to >6000 and >70xy, where xy is a byte of the filename you want to load. Right now bank switches and image selection are temporally separate, but if image selection must always be active then you have a conflict with games like Pac-Man that use absurd addresses for bank selection, which would be interpreted as image selection.

 

Yeah, I don't know how it could work. But it would be cool if you could store hundreds of MB of video on a SD card and play it seamlessly from the TI. Think Dragons Lair... .

[Tursi]

I haven't tried it yet. I'd also need some extra logic to tell console GROMs from cart GROMs. But someone said that the GRAM Kracker "just shouts louder", so maybe it could work.

 

It should work fine. The UberGROM has no problem overriding the console GROMs. The reason I disabled it was because I hadn't finalized the design for the MPD, which will also run an AVR for GROM emulation, and I didn't want two TTL-style devices fighting on the bus. I also didn't intend the device to be used as a GRAM replacement.

 

You do need accurate address readback emulation to replace the GROMs, although you can "shout" over them without implementing it. (As long as you implement the prefetch behavior internally, the address emulation should come easy. If you short-cut it like we're all tempted to do, there are a couple of specific cases in the console GROMs that will trip it up. I can't remember exactly /where/ it was, but there was an unexpected sequence of readback and updating that didn't work correctly for me until I implemented the prefetch.)

[brain]

 

 

It's not that easy. The main problem is that you'd have to distinguish bank switches from image selection. Selecting a game is alternating writes to >6000 and >70xy, where xy is a byte of the filename you want to load. Right now bank switches and image selection are temporally separate, but if image selection must always be active then you have a conflict with games like Pac-Man that use absurd addresses for bank selection, which would be interpreted as image selection.

Can you comment more on this? It sounds like you are using the _we on >7000 to simulate a clock, and a write to >6000 to be the data, but why is the clk strobe needed? Why can't one simply write to >6000 to get data into the unit?

 

Also, on the original request, I have a way you can distinguish.

 

If you have some spare MCs in your CPLD, you can implement a state machine and "hide" the image selection registers. Basically:

 

Watch for writes to a specific address, say >7002 (but could be anything)

Each time, watch to see if they come in some specific order:

>aa

>55

>'T'

>'I'

 

or something like that,

each time you see a specific value, increment a counter. If you don't see the right value at the right time, reset the counter to 0:

always @(negedge clock, posedge reset)

begin
  if(reset)
        state <= 0;
  else
        case(state)
         0:
                if(data == 8'h55)
                    state <= 1;
            1:
                if(data == 8'haa)
                    state <= 2;
                else
                    state <= 0;
            2:
                if(data == magic1)
                    state <= 3;
                else
                    state <= 0;
            3:
                if(data == 8'h01)
                    state <= 4;
                else
                    state <= 0;
            default:
               state <= 0;
        endcase
end

Then, once state = 4, bring the image selection logic back into the address space, and hide the bank selection logic. It looks like a lot of MCs, but the above only take 3 or 4, and will allow you to support both things. The above is from a Xilinx 95144xl project I did for the coco and the VIC-20, but should work fine on the TI. Just use !_we as clock.

 

Jim

 

 

[ralphb]

Thanks for your suggestions, Jim.

 

Can you comment more on this? It sounds like you are using the _we on >7000 to simulate a clock, and a write to >6000 to be the data, but why is the clk strobe needed? Why can't one simply write to >6000 to get data into the unit?

 

I'm writing any value to >70xy, where xy is the value I want to send. And I write anything to >6000 to signal the microcontroller that a new byte will be sent. Yes, I could write xy to >6000 instead, but I'd still need some sort of marker bit. I guess I could alternate between sending xy and 00.

 

But mostly I adopted this method from the FlashROM, which had no other way of transmitting data than using the bank switch register. There's no shortage of pins on the microcontroller, so I kept it.

 

Also, on the original request, I have a way you can distinguish.

If you have some spare MCs in your CPLD, you can implement a state machine and "hide" the image selection registers. Basically:

Watch for writes to a specific address, say >7002 (but could be anything)

Each time, watch to see if they come in some specific order:

 

 

Yes, that's a method I had detailed to Rasmus somewhere in the FlashROM thread, where he raised this request as well. In fact, I probably wouldn't implement this in the CPLD, but in the microcontroller. Alright, I'll think about this ... but there's a lot of stuff to think about now!

[ralphb]

 

It should work fine. The UberGROM has no problem overriding the console GROMs. The reason I disabled it was because I hadn't finalized the design for the MPD, which will also run an AVR for GROM emulation, and I didn't want two TTL-style devices fighting on the bus. I also didn't intend the device to be used as a GRAM replacement.

 

You do need accurate address readback emulation to replace the GROMs, although you can "shout" over them without implementing it. (As long as you implement the prefetch behavior internally, the address emulation should come easy. If you short-cut it like we're all tempted to do, there are a couple of specific cases in the console GROMs that will trip it up. I can't remember exactly /where/ it was, but there was an unexpected sequence of readback and updating that didn't work correctly for me until I implemented the prefetch.)

 

Thanks for that summary, Tursi!

 

So in other words, I would have to implement address read anyway, right? Let's see if I can add another rule to the GROM address register.

[Tursi]

 

Thanks for that summary, Tursi!

 

So in other words, I would have to implement address read anyway, right? Let's see if I can add another rule to the GROM address register.

 

You have to implement it if you want to replace the built-in GROMs. If you're okay leaving them there, then you don't need to.

 

All that considered, I don't know the long term effects of directly overriding the internal GROMs, whether it will hurt them. I expect from previous GRAM devices that it's fine, but I also don't know if they did anything to mitigate it. I didn't measure current draw or anything.

[brain]

Thanks for your suggestions, Jim.

 

 

I'm writing any value to >70xy, where xy is the value I want to send. And I write anything to >6000 to signal the microcontroller that a new byte will be sent. Yes, I could write xy to >6000 instead, but I'd still need some sort of marker bit. I guess I could alternate between sending xy and 00.

 

But mostly I adopted this method from the FlashROM, which had no other way of transmitting data than using the bank switch register. There's no shortage of pins on the microcontroller, so I kept it.

 

 

Yes, that's a method I had detailed to Rasmus somewhere in the FlashROM thread, where he raised this request as well. In fact, I probably wouldn't implement this in the CPLD, but in the microcontroller. Alright, I'll think about this ... but there's a lot of stuff to think about now!

On the first item, I don't think the second write is needed.

 

I assume that the CPLD creates an interrupt to the uC when a write to >7000 is processed (I assume it is assign UC_INT = !_ROMG & (address[12:0] = <7000, but just bits 12:0 of it>) & !_WE;)

 

and then you latch any write to >60xx, which is then presented to the uC. I was jsut suggesting that the INT could be set to be the same write of data.

 

However, I do understand the ease of re-using code. I was just trying to determine the need for the second write. The nice thing is, my tweak doesn't require the >60xy write to be removed, it just becomes ignored.

 

Do you do most of the stuff in the uC now, or did you move GROM functionality into the CPLD? I assume you put the bank register into the CPLD, and have a mux that allows the uC to address the RAM through the CPLD, but is there anything else in there? (or did you run the uC at 3V3 and hook it up directly to the RAM?)

[ralphb]

On the first item, I don't think the second write is needed.

I assume that the CPLD creates an interrupt to the uC when a write to >7000 is processed (I assume it is assign UC_INT = !_ROMG & (address[12:0] = <7000, but just bits 12:0 of it>) & !_WE;)

and then you latch any write to >60xx, which is then presented to the uC. I was jsut suggesting that the INT could be set to be the same write of data.

 

Interesting technique! I didn't think of interrupts.

 

Do you do most of the stuff in the uC now, or did you move GROM functionality into the CPLD? I assume you put the bank register into the CPLD, and have a mux that allows the uC to address the RAM through the CPLD, but is there anything else in there? (or did you run the uC at 3V3 and hook it up directly to the RAM?)

 

The µC still has the same jobs as in the FlashROM, mostly SD card handling and image generation.

 

The CPLD handles the SRAM (i.e., all ROM and ROM reads as well as the sequential µC writes), switches the banks, and emulates the GROMs. There are some irritating resource drainers like the bank register, the bank mask, the current GROM, the GROM mask, the selection register ... it quickly sums up.

 

Originally I tried to use just one address counter for both GROM and RAM loader, but the mess ... all in all I'm at about 96 macrocells now, but it's not done yet.

 

The µC cannot write directly to the RAM, as there are not enough pins on the µC. I also thought about serial RAM, but I figured it might not be fast enough.

[ralphb]

Oh, and last night I frizzed my dev board by touching it. I could feel the static in my fingers.

 

Probably it wasn't the best idea to put a shag carpet right in front of my solder workplace.

[Omega-TI]

I'm sorry to hear that. I feel for you.

[Sinphaltimus]

Oh, and last night I frizzed my dev board by touching it. I could feel the static in my fingers.

 

Probably it wasn't the best idea to put a shag carpet right in front of my solder workplace.

Dev boards should come with lightning rods.

[brain]

Oh, and last night I frizzed my dev board by touching it. I could feel the static in my fingers.

 

Probably it wasn't the best idea to put a shag carpet right in front of my solder workplace.

Well, if you're open to some help, I have some premade dev boards here that I designed to allow me to debug my GROM CPLD code (which is *almost* working, but I digress), that I could send. They have the xc95144xl CPLD footprint all connected to 512kB of SRAM and the TI bus (all signals), and a breakout header for other stuff (your uC, I assume). You're free to have one if that helps get your development going again.

Edited January 24, 2017 by brain

[ralphb]

Well, if you're open to some help, I have some premade dev boards here that I designed to allow me to debug my GROM CPLD code (which is *almost* working, but I digress), that I could send. They have the xc95144xl CPLD footprint all connected to 512kB of SRAM and the TI bus (all signals), and a breakout header for other stuff (your uC, I assume). You're free to have one if that helps get your development going again.

 

Thanks for the offer, but no worries. For the prototype I got 10 PCBs with parts, and the fried cart was #6. Cart #7 has already been built and is running again.

[+jedimatt42]

Oh, and last night I frizzed my dev board by touching it. I could feel the static in my fingers.

 

Probably it wasn't the best idea to put a shag carpet right in front of my solder workplace.

 

Bare foot. That's my anti-static solution.

[+Lee Stewart]

 

Bare foot. That's my anti-static solution.

 

I am usually barefoot in my house, but I always touch bare metal before touching electronic components I am messing with. I prefer metal that is grounded, but that is not a requirement.

 

...lee

[+Vorticon]

 

I am usually barefoot in my house, but I always touch bare metal before touching electronic components I am messing with. I prefer metal that is grounded, but that is not a requirement.

 

...lee

 

How very hippy of you guys I have super flat fleet, and if I walk barefoot for any extended period of time, I get back aches...

So I've grown the habit of touching my PEB before doing anything with the TI or other electronics. It's become a ritual...

[+jedimatt42]

 

How very hippy of you guys I have super flat fleet, and if I walk barefoot for any extended period of time, I get back aches...

So I've grown the habit of touching my PEB before doing anything with the TI or other electronics. It's become a ritual...

 

I suppose that could work too

 

-M@

[Omega-TI]

 

So I've grown the habit of touching my PEB before doing anything with the TI or other electronics. It's become a ritual...

 

I love it! Who ever said, "A 36 year old computer has no practical purpose"... is full of __it!

That just another reason to buy a P-Box folks!!

[+OLD CS1]

Oh, and last night I frizzed my dev board by touching it. I could feel the static in my fingers.

 

Probably it wasn't the best idea to put a shag carpet right in front of my solder workplace.

 

I can spare a few...

 

[AuTomato]

 

Must... have...