Cartridge burning questions

[TheMole]

I have a couple of questions regarding burning my own carts.

 

- First of all, are there any carts that can be programmed by the TI, or do you always need an EEPROM programmer?

- Secondly, I seem to remember reading that the ubergrom cart can ensure that the ROM portion of the cart starts up in the first bank, whereas the ROM-only carts need a header in every bank. Is this true, or am I making stuff up?

- Thirdly, what is the most efficient way to set up a cart for development purposes (which cart, ROM or UberGROM, which programmer, ...)

 

Thanks!

[Tursi]

As far as I know all the available carts require an EEPROM programmer, unless your title is GROM /only/. The UberGROM can be programmed by the TI once it's been initialized.

 

For startup, you have a lot of options:

 

-The UberGROM can force the ROM bank on startup because GPL allows for a powerup bank, so you can run any code you like there.

-Otherwise, the solution that I prefer is to have a startup header in every bank (most banks only need enough space for the header and the bank switch itself, which can be done in 32 bytes or so.) That ensures that no matter the state of the hardware, it will always come up correctly.

-There are a number of carts that get by just fine having powerup in only the hardware reset bank, including the early multicarts, but those may require a power-cycle to properly reset.

-There's also a version of the bank switch chip (I can't remember which one it is) which has a reset line and can be forced to a known state at startup - but this may require additional wiring and will not handle the FCTN-= case (which is a software reset).

-Another method is to disable FCTN-= and handle reset manually in your software, setting the correct bank before you exit. This works for all cases except people with a hardware reset button (such as on a widget).

-The copy cart I just looked at always set the startup bank after performing its copy, so that it was ready to go on reset. This works if you don't need to flip pages during runtime.

 

There's probably more, but these are the ones I've seen.

 

I can't help much for the third one, not too many of my experiments fall under the theme of efficient.

[Omega-TI]

This is a great topic Mole! We've needed a "BURNINING 101" thread for a while now.

I've glanced at a few messages here and there over the past year, but they've raised more questions than answers. I'd like to see things laid out in an easy to follow step by step process. I've been strapped for time lately, and figured this would take too much of a time investment, because I've read about things I've not wanted to have to deal with like:

 

1) Inverted stuff...

2) Sub-par sockets...

3) Headers...

4) Which burning program...

5) Programming issues...

6) Program settings...

7) Which burner...

Bricked chips

9) Sourcing everything...

 

 

Jumping into the deep end of the pool usually leaves one under water. If you don't know how to swim, a flotation device is needed...

 

1) Which cart do the experts recommend that does not require inverting stuff? The Uber Cart ? How much is it and where do we buy it?

2) Which burner and socket is recommended for the carts IC? How much does all this stuff cost and where can we buy it?

3) Where is the best place to purchase affordable chips THAT WORK?

4) The software is going to be a the deep end of the pool for a NOOB, so.....

 

How about a You Tube video walking us unwashed masses through the procedure is such a simple manner that even a first grader could follow along?

 

Since I'm asking for the Moon right now, I might as well also ask for a parts list with sources for a proper 'starter kit' that would get all us interested parties up and running.

[+Lee Stewart]

I have a couple of questions regarding burning my own carts.

 

- First of all, are there any carts that can be programmed by the TI, or do you always need an EEPROM programmer?

- Secondly, I seem to remember reading that the ubergrom cart can ensure that the ROM portion of the cart starts up in the first bank, whereas the ROM-only carts need a header in every bank. Is this true, or am I making stuff up?

- Thirdly, what is the most efficient way to set up a cart for development purposes (which cart, ROM or UberGROM, which programmer, ...)

 

Thanks!

 

For #3, at the very least, you should have a ZIF socket for the ((E)E)PROM on whichever card you choose. That makes development/testing a lot easier. I have just such a 512K card.

 

...lee

[Tursi]

Mole's actually asking about the software side, Omega -- actually creating the image itself. But why not start the thread you mention yourself? There are lots of people who can help out with covering the actual burning side once you have the image. You'll find some of your concerns there are only relevant to the creator.

[+Ksarul]

The Red boards do have the option of using an NV SRAM chip. . .which may help here. No one has tested that functionality yet, so it may be a bit of an adventure to ensure you get a loader that can do what you need (you may need to load banks individually, using a write protect switch to prevent interference at switch points while loading). There's a header to write protect on the board. . .

[TheMole]

Isn't NV SRAM uber expensive at those sizes though? I was looking for a 512kB size chip on mouser and they're around $100!

 

Does the atmega on the ubergrom board have access to the 512k ROM? If so, it should be feasible to add something like this to the atmega's SPI interface and replace the ROM chip with a non-NV (making it a non-non-volatile? ) SRAM chip. (Even if this isn't the case, you can route the data through the host system, I guess). But that's way beyond my skill level .

 

Either way, I'm ordering my ubergrom cart today or tomorrow and will purchase an appropriate EPROM burner as well for testing Alex Kidd on real iron.

[+Ksarul]

Note that the 512K chip on an UberGROM board is a 49F040 (or a 29F040), in PLCC32 form. These are Flash chips, and there is a jumper on there to allow you to program it on the board, but the software to do that hasn't been written by anyone yet. . .

 

Let me know if you need some of the flash chips--I have a large supply of them (I think I still have about 2,000 of them left from my original buy).

[+mizapf]

Can the "UberGROM" be programmed in-system? This would be essential for the emulation in MESS because I would have to use the NVRAM feature instead of using a fixed ROM dump.

[Tursi]

The contents of the "UberGROM" are meant to be programmed in system. the AVR code can not be.

 

Source for my test program is supposed to be distributed with the chip, let me know if it's not and I'll provide that. The PDF documentation also describes in detail how to use and program it.

[+mizapf]

OK, I'll have a look. Just for a short summary, is writing done directly like a GRAM, or by explicit Flash procedure (CFI sequence etc.)?

 

==

 

Also, as a notice, I'll be AFK for an overseas holiday for about two weeks, starting today. (Overseas from our perspective. ) Round tour through LA, LV, SFX.

 

==

[Tursi]

By explicit flash procedure, although the command set has been simplified and abstracted. But the concept is similar, you send a page erase command, you fill a buffer, and you send a flash write command. This all does happen through "GRAM" writes.

 

To be compatible, you will also need to implement at a minimum the EEPROM and the mapping configuration (the mapping is stored in the EEPROM), otherwise you won't know what addresses the flash controller is responding too. EEPROM is simpler, supporting read and write as if it were GRAM, but it must be unlocked with a particular sequence before you can write to it (to avoid accidentally corrupting the configuration).

 

The XB27 cart also requires the RAM to be emulated to support the "boot loader" that Gazoo added - the cartridge offers 15k of GRAM, mappable as one 8k bank and one 7k bank. (Most of the cart will work without this however). Once mapped, there's nothing weird about this, it reads and writes as normal GRAM.

 

Nobody as far as I know has yet used the timer, the USART, the GPIO, or the ADC features.

 

Have fun in the states!!

[RickyDean]

So Tursi, what I seem to infer from what you are saying here, is that it is possible to use eeprom chips in a Horizon ram-disk for example and write a program to unlock the eeprom, fill it with content, lock it back and enjoy the results? I had thought of this 15 years ago, using my Mechatronic eprommer and eproms, but didn't get to pursue that, do to family circumstances. Is it possible?

[RickyDean]

And maybe this should be another topic?

[Omega-TI]

Nobody as far as I know has yet used the timer, the USART, the GPIO, or the ADC features

 

Tursi, you really know how to tease a guy. Could these be readily and easily interfaced? If so this opens up a lot of opportunities for future growth/expansion... and sheer hobby enjoyment.

 

How fast is this USART? Could this be used as a practical interface between a future storage device?

An analog to digital converter huh? That opens up many cool possibilities!

[Tursi]

So Tursi, what I seem to infer from what you are saying here, is that it is possible to use eeprom chips in a Horizon ram-disk for example and write a program to unlock the eeprom, fill it with content, lock it back and enjoy the results? I had thought of this 15 years ago, using my Mechatronic eprommer and eproms, but didn't get to pursue that, do to family circumstances. Is it possible?

No, we're specifically talking about the "UberGROM", which is based on an AVR and has all of these memory types built into it. The shipped software provides a GRAM-like interface to these built-in peripherals.

[Tursi]

Tursi, you really know how to tease a guy. Could these be readily and easily interfaced? If so this opens up a lot of opportunities for future growth/expansion... and sheer hobby enjoyment.

 

How fast is this USART? Could this be used as a practical interface between a future storage device?

An analog to digital converter huh? That opens up many cool possibilities!

I teased you about it five years ago. It's a shipped product now.

 

All access to the chip is through the GROM/GRAM interface, just reads and writes. The documentation covers each peripheral in detail (hopefully enough).

 

There are 4 ADCs (5v, 8-bit) and six digital GPIO with optional internal pull-up. The ADCs are probably not fast enough for audio sampling (something I considered), but they run about at the speed of the GROM bus. (My notes report a conversion speed of 104uS, the memory access is a fair bit slower).

 

The USART exposes the full configuration space of the AVR USART: 5-8 bits, Parity of even/odd/none, 1/2 stop bits, and double clock mode. In normal mode it will do from 122bps to about 500,000bps over 4096 steps. The "2X" mode doubles this, but with half the clock recovery accuracy. The code implements two 256 bytes buffers, one for each direction, so it can receive bursts at high speed as long as the sender will wait for the TI to catch up, I had XMODEM in mind when I did that. Receiving more than 256 bytes will overrun the buffer though. The intent was interface to devices more than communications, but you could do communications with hardware flow control by bringing the GPIO into play, potentially (but if someone wanted a custom one for communications purposes, the code changes to make a larger buffer and automatic flow control on full buffer would be easy).

 

I should add, I tested that 500k received data okay, but you wouldn't want continuous streams of very high speed data coming in. The GROM port is handled by polling, and USART characters by interrupt. You could in theory receive data hard enough to cause the TI to get corrupted data due to the lines not changing (although I did not observe this). It's the sort of thing you would test very hard if you wanted to use it.

Edited August 28, 2015 by Tursi