Jump to content
IGNORED

"Bad Apple" on cartridge


OLD CS1

Recommended Posts

8 hours ago, brain said:

The 32MB version would probably be best to use PSRAM, as it's cheaper and can get in larger packages without going to full DRAM.

Ignore.  I forgot we were talking about ROM, not RAM.  ROM's are available in much larger sizes.

 

Looking at Digikey right now, the S29GL01GT10TFI020 looks to be a good option.  1 IC, 128MB in the package, FLASH, 8 bit data path (16 is also supported, but not needed here).  It's $10.53 in singles, but that's not bad, all things considered, and it's in stock.

 

image.thumb.png.ece7ea957f5463853751504cd83fa298.png

Jim

Edited by brain
  • Like 2
Link to comment
Share on other sites

I need to measure a real cart PCB, but I'm out of town right now, and I didn't see any measurement postings with a quick Google search.  Links are welcome, or I'll micrometer one when I get home. I think there might be a screw hole needed as well.

  • Like 1
Link to comment
Share on other sites

Well, as for Tursi's lack of 'quality' sound sources...

 

I pulled the original .flv, as backed up by archive.org.  The original has very 'muddy' vocal track. I think the reverb distortion is intentional.

https://archive.org/details/TouhouBadApple

 

I found a reasonably pliant .mid file that needs a good quality soundfont. It has (easily silenced) instrumental stand-in for the vocal tack however.

In theory, a good rendering of the vocal track could be made with something like vocaloid, and then muxed with a good rendering of the midi score with the 'false vocals' silenced.

  • Like 1
Link to comment
Share on other sites

10 hours ago, brain said:

Thanks, search yielded that and I can fire up KiCAD to grab them from FinalGROM, but I always try first to get official measurements of an "in the day" TI cart, to be as accurate as possible.

 

Jim

All of the cartridge boards I make are dimensionally-correct analogues of the original TI cartridge boards. We designed them that way on purpose so that they would match up to the TI cartridge cases. My layouts are in ExpressPCB or RobotRoom formats though.

Link to comment
Share on other sites

I assume they did it to save ICs, as latching the address requires only no address decoding.  Sigh.  What a non future proof design tenet.

 

Ah, so a write latched the data lines, under the proviso that there's no other writes on the cart bus.  But, if that's the case, then why is not the Dragon Lair cart already used for this idea (Bad Apple)?  Seems like 128MB is already done.

 

Jim

 

Probably want to keep with the same bank switching scheme with the write to rom. A lot of the cartridge makers and such are already written for that and would just need to be extended for extra banks beyond the 2MB that everyone has written them for. The data write to rom to switch banks is easy. Write to >6000 gives you 8K bank 0, >6002 to 8K bank 1, etc.

 

As Tursi said, we can do 32MB with writes to rom with the the available address lines in the cart port. We would just add the remaining ones over the 8 that the 2MB board has an then use a PLD to do the bank switching.

 

You can find Gerbers for my 64K bank switched cart here if you want dimensions: http://www.hexbus.com/bin/64k_cart.zip. I measured these with a micrometer back in the day. And all successors that@ksarul has made use these old boards I believe.

 

Also, Stuart wrote a great article about bank switching way back when: http://www.stuartconner.me.uk/ti/ti.htm#bank_switching

  • Like 2
Link to comment
Share on other sites

On 7/23/2022 at 6:46 PM, Tursi said:

That's why I used a CPLD. Had enough lines to manage both the bank switching and the voltage conversion. That said, even 5v tolerant CPLDs are getting hard to come by. ?

 

Is there a "level shifting array" type IC made that can assist with something like this?   I've changed the voltage of the UberGROM's 1284P to 3.3V (it's a 1284P programming option) so that I could use a 3.3V ESP board on the +5V cart voltage rail - it seemed fine with 3.3V being the voltage while still having 5V signals coming in from the /4A.  Has anyone ever done tolerance tests with the address and data lines on the cart port to see what the voltage thresholds are?

 

Link to comment
Share on other sites

1 hour ago, acadiel said:

Has anyone ever done tolerance tests with the address and data lines on the cart port to see what the voltage thresholds are?

This would be interesting.  I read somewhere sometime that TTL high can start as low as 3.5V.

Link to comment
Share on other sites

On 7/23/2022 at 11:47 PM, brain said:

I assume they did it to save ICs, as latching the address requires only no address decoding.  Sigh.  What a non future proof design tenet.

 

Ah, so a write latched the data lines, under the proviso that there's no other writes on the cart bus.  But, if that's the case, then why is not the Dragon Lair cart already used for this idea (Bad Apple)?  Seems like 128MB is already done.

 

Nobody asked. ;)

 

Programming my 128MB cart is a bit of a pain in the butt. I think it's possible to write a CPLD load that would make programming easier, but I didn't. Right now the programming is done via the TI cart port using a hacked console. So although everything is freely released, it's a long ways from generally useful.

 

Link to comment
Share on other sites

On 7/23/2022 at 11:49 PM, brain said:

Can you do a 16 bit write to the cart part @ >6000 and if so, does the cart port see a $6000 write of 8 bits followed by a $6001 write of 8 bits?

Yes. Although I believe the LSB is accessed first.

Link to comment
Share on other sites

On 7/24/2022 at 12:42 AM, brain said:

Ignore.  I forgot we were talking about ROM, not RAM.  ROM's are available in much larger sizes.

 

Looking at Digikey right now, the S29GL01GT10TFI020 looks to be a good option.  1 IC, 128MB in the package, FLASH, 8 bit data path (16 is also supported, but not needed here).  It's $10.53 in singles, but that's not bad, all things considered, and it's in stock.

Same part I used. The reset sequence is /really/ touchy. I ended up having to have the CPLD control the reset to get the chip to come up clean.

Link to comment
Share on other sites

1 hour ago, acadiel said:

Is there a "level shifting array" type IC made that can assist with something like this?   I've changed the voltage of the UberGROM's 1284P to 3.3V (it's a 1284P programming option) so that I could use a 3.3V ESP board on the +5V cart voltage rail - it seemed fine with 3.3V being the voltage while still having 5V signals coming in from the /4A.  Has anyone ever done tolerance tests with the address and data lines on the cart port to see what the voltage thresholds are?

 

SN74ALVC164245

Lots of companies sell similar, and they all have 164245 or similar in the part number.  This one is 16 bits in length.

 

You'd need to check the AVR pins to see if they have clamping diodes. Many IO devices like that do have them, and they don't like being driven beyond VCC (in effect, the clamping diode tries to keep the input 5V down at 3V3, and so sheds quite a bit of heat in that mode).

 

Jim

Link to comment
Share on other sites

2 hours ago, acadiel said:

Is there a "level shifting array" type IC made that can assist with something like this?   I've changed the voltage of the UberGROM's 1284P to 3.3V (it's a 1284P programming option) so that I could use a 3.3V ESP board on the +5V cart voltage rail - it seemed fine with 3.3V being the voltage while still having 5V signals coming in from the /4A.  Has anyone ever done tolerance tests with the address and data lines on the cart port to see what the voltage thresholds are?

 

Yeah, most (not all! Watch the datasheet...) of the I/O on the AVR remains 5v tolerant at 3.3v. I've run that way too. In fact, my very first prototype ran that way for the same reason - it was interfacing to a 3.3v Linux board (well before the Raspberry Pi existed! ;) ). The datasheet covers this quite well.

 

There are dedicated level shifting chips - they work well but of course - part count goes up. 

 

Dragon's Lair is also 3.3v back to the TI, through the CPLD.

 

 

Edited by Tursi
Link to comment
Share on other sites

5 hours ago, Tursi said:

Yeah, it's a little easier 7 years later. Go back to 2015 and taunt me again. ;)

 

Not really taunting.. more pointing out that a clean vocal track version does not seem to exist. The original smashed the audio envelope badly.

 

The track in question is the 'niconico' version. 'Niconico' is apparently the vocaloid voice used. The original touhou game musical score is more.. piano. The 'pliant' midi I rounded up is the niconico version, and seems to timesync with the flash animation.

 

I have been having difficulty tracking down a suitable GMGS soundfont to render the instrumental portion. I think it was rendered originally with multiple midi devices, or maybe a mod tracker. The instruments sound like fancy triangle waves to me.

 

The closest match I have so far combines 'OmegaGMGS.sf2' and a YamahaXM soundfont. The drums from the XM soundfont are necessary.

 

I'm just trying to get you a non-crushed audio source.

 

  • Like 1
Link to comment
Share on other sites

55 minutes ago, wierd_w said:

Not really taunting.. more pointing out that a clean vocal track version does not seem to exist. The original smashed the audio envelope badly.

 

The track in question is the 'niconico' version. 'Niconico' is apparently the vocaloid voice used. The original touhou game musical score is more.. piano. The 'pliant' midi I rounded up is the niconico version, and seems to timesync with the flash animation.

 

I have been having difficulty tracking down a suitable GMGS soundfont to render the instrumental portion. I think it was rendered originally with multiple midi devices, or maybe a mod tracker. The instruments sound like fancy triangle waves to me.

 

The closest match I have so far combines 'OmegaGMGS.sf2' and a YamahaXM soundfont. The drums from the XM soundfont are necessary.

 

I'm just trying to get you a non-crushed audio source.

 

That's fair, sorry for the snark. :)

 

The one I pulled for the remade version seemed a little cleaner - at the very least every single bass beat wasn't clipping, so I was satisfied with it. It's possible that it was just lower volume. ;)

 

Link to comment
Share on other sites

3 hours ago, Tursi said:

That's fair, sorry for the snark. :)

 

The one I pulled for the remade version seemed a little cleaner - at the very least every single bass beat wasn't clipping, so I was satisfied with it. It's possible that it was just lower volume. ;)

 

There are apparently "Anniversary Edition" CDDA tracks floating around that might be worth exploring, but the ones I have listened to have clipped/smashed vocals.  It might be that the voice banks used were just shit, I don't know.  Just pointing out that these additional sources do seem to exist, I just considered them unsuitable.

 

The author seems to not understand that the "loudness war" of the 90s and early 2000s was a bad thing, as the pieces always clip the envelope from amplitude crush.

Edited by wierd_w
Link to comment
Share on other sites

22 hours ago, Tursi said:

Same part I used. The reset sequence is /really/ touchy. I ended up having to have the CPLD control the reset to get the chip to come up clean.

Is your design available somewhere?  Did you use the CRUCLK or something to hold off reset for a bit, or was there some otehr trick?  I like this FLASH ROM, and I'd like to use it in a couple projects, but hate to re-invent the wheel.

 

jim

 

Link to comment
Share on other sites

4 hours ago, brain said:

Is your design available somewhere?  Did you use the CRUCLK or something to hold off reset for a bit, or was there some otehr trick?  I like this FLASH ROM, and I'd like to use it in a couple projects, but hate to re-invent the wheel.

 

jim

 

his github?

 

Link to comment
Share on other sites

10 hours ago, brain said:

Is your design available somewhere?  Did you use the CRUCLK or something to hold off reset for a bit, or was there some otehr trick?  I like this FLASH ROM, and I'd like to use it in a couple projects, but hate to re-invent the wheel.

Looking at my code, I see two issues. One is that I'm not ultimately sure which folders were the final build (!), and the other is that I had to support two generations of the flash chip.

 

The oldest version, which I think is cpld.programLoad/design_first_working_dragons_lair.vhd, uses the older version of the flash and this is the one that had the really touchy reset sequence. If it wasn't properly managed per the datasheet timing, entire erase pages of the flash would just fail to respond, randomly. The requirement was to hold it in reset for 35uS, and my notes suggest that even coming close (around 32uS) seemed still to be not good enough. It was surprisingly hard to find a "first" access that was slower than that. ;)

 

Since resources were really tight, it looks like earlier attempts that counted GRMCLK (and one that is listed as working that counted transitions on A15) were abandoned, and instead I tied the reset line to my GROM active signal (grmpage), which was set only when the console was trying to access my little emulated GROM. The game still worked from ROM since  the GROM had to be selected first, and then that page would stay active for the entire run of software. Not recommending this for future designs. ;)

 

My manufactured board used a later chip, and I called this the "seahorse" board cause of the different image. The startup requirements for this chip were not as severe, and I held the reset line high and merely manipulated chip enable successfully. The scary timing was not quite as bad, except that I seem to recall the chip had a much longer startup time that caused me some concern (but appears not to have bitten me). It appears that it transitioned from a pure logic device to a software-driven device internally, thus the new timing requirements. Likely you'd be on the newer version. But that design looks like cpld.seahorseLoad/design.vhd. I was not completely thrilled with this approach and would do it differently, but as built I could control CE /or/ Reset, not both, meaning I played games with it till it worked.

 

Follow the datasheet recommendations carefully - even the single-statement throwaway lines (this was how the reset criteria was noted in the first one) - and you'll be fine. ;)

 

Also, expect the VHDL to be primitive. It was my first (and still only!) VHDL project. Optimizations are probably possible and any you see, I wouldn't mind learning ;)

 

The project is here: https://github.com/tursilion/gigacart

 

 

 

  • Like 3
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...