Jump to content
IGNORED

Preparing an AVR as an UberGROM


Tursi

Recommended Posts

There are only two things you need to do to turn an AVR into an UberGROM. (After that, use it on the board in the TI and stop thinking of it as an AVR, it's a product at that point. ;) ). You can and should load software with GROMCFG, or even the standalone loader GROMLOAD, unless you know better - that tool is meant to make it easier to distribute and load finished images. People are free to distribute the standalone loading tool with their products.

 

Those two things are :

- set the fuses

- load the firmware

 

The fuses are the configuration settings for the microcontroller. On my VS4800's "VSPEED" software it's under "Set->Config or Encrypt". Every AVR has a slightly different set, but the 1284P has the following settings which should be SOMEWHERE on the relevant dialog. The settings are just bytes, but most programmers split them up into checkboxes for ease of writing. Mine looks like this:

 

post-12959-0-27039700-1445139675_thumb.jpg

 

First is the lock bit byte, containing:

 

BLB01, BLB02, BLB11, BLB12 - These set the lock mode for the boot block

LB1, LB2 - These set the lock mode for the rest of the memory

 

These are used to secure the chip against accidental writes and against reading back the data. Since we need to be able to write to the chip and we aren't trying to hide the code, they should all be unset (and on the AVR, unset is a '1'). So nothing selected, and the final byte value should be 0xFF. (Some tools like the VSPEED I use writes hex with an 'H', so 'FFH' instead).

 

Don't play with these settings to see how they work unless you are prepared to erase the full chip and start from blank again - they can not be unchecked without a chip erase. (They wouldn't be very good security otherwise! :) )

 

The "Extended Fuse Byte" has just three bits defined:

 

BODLEVEL0, BODLEVEL1, BODLEVEL2 - this sets the level of a Brown-out detector. It's purpose is to hold the chip in reset when the voltage is too low to operate. Setting 0 and 1 puts the brown out voltage at 4.3V, which I recommended just in case the TI power supply comes up unevenly. The AVR can run just fine down to 3v, so that level ensures power is stable when it starts. This results in a write value of 0xFC.

 

The "Fuse High Byte" might also be presented as the high byte of a 16-bit value. I'll split it into High and Low because that's what the datasheet does. The high byte sets 8 bits:

 

OCDEN - enables an on-chip debug mode that runs the clocks even in sleep mode. Should be DISABLED.

JTAGEN - enables the JTAG debug interface. MUST be DISABLED (we use the pins to talk to the TI).

SPIEN - enable serial programming mode. I often use this so I leave it ENABLED.

WDTON - Watchdog timer always on. The software doesn't use watchdog so this MUST be DISABLED.

EESAVE - preserves EEPROM during chip erase. For UberGROM leave it DISABLED.

BOOTSZ1,BOOTSZ0 - sets the size of the boot memory (firmware in this case). Both MUST be ENABLED which results in an 8k boot area.

BOOTRST - moves the reset vector to the start of the boot memory. MUST be ENABLED.

 

This results in a high byte value of 0xD8.

 

The "Fuse Low Byte" has these 8 bits:

 

CKDIV8 - divides the system clock by 8. Should be DISABLED unless you like a really slow system. ;)

CKOUT - outputs the clock on one of the pins. MUST be DISABLED (we use that pin to talk to the TI)

SUT1,SUT0 - start up time delay. Both should be ENABLED which is fastest start because the brown out detector will watch the power for us in hardware.

CLKSEL3,CKSEL2,CKSEL1,CKSEL0 - clock selection. All but CKSEL1 MUST be ENABLED, CKSEL1 MUST be DISABLED. This selects the internal 8MHz clock.

 

This results in a low byte value of 0xC2.

 

It was those CLKSEL bits that were giving people problems. If they are set to (almost) ANYTHING ELSE, then the chip has been told to use an external clock. With no clock, nothing happens, so it appears to be dead. Nothing is broken or bricked, they told it to use an external clock then didn't attach an external clock! This is where we were talking about getting an external oscillator to feed a clock signal for recovery - I posted a picture showing that it even works just dangling from three wires. It's more than enough to get in and fix the fuse setting anyway. ;)

 

Anyway, once those fuse bits are set, program and verify them (on VSPEED it's just clicking 'ok' then reloading the dialog to make sure it took).

 

That was the hard part. Loading the firmware is just like programming a flash chip. Almost. ;)

 

Download the archive from my website (http://harmlesslion.com/software/grom). Of all the stuff in the archive, the only thing you care about is "ubergrom.hex".

 

Remember when I told you all the files you load into your programmer are BINARY until you know better? Here's a case where you know better. ;) "Intel Hex" is a common old-school way for program images to be passed around - it's literally a text file containing the hex bytes in readable ASCII, with some special formatting and checksums for good measure.

 

So when you go to load the data, tell your software that it's an Intel HEX file. Leave the offsets all default -- Intel HEX files also contain address pointers, so it should load to the right place. After it loads, your buffer should be all FF until you scroll all the way down to 0x1E000 (note the number of digits - more than 64k!). This is the bootloader area of the chip. You'll want to double-check that. On mine it looks like this:

 

post-12959-0-33728500-1445139669_thumb.jpg

 

Go ahead and program that. When it's done, it's ready to load into the UberGROM board and run on the TI. You do not need the 512k flash chip to run the GROM, and you do not need the GROM to run the 512k flash chip -- so you can go ahead and test the GROM before you worry about the flash.

 

You only ever need to do the above steps once! Unless it somehow becomes corrupted (which I have never seen happen!), the firmware will stay put no matter what you do on the TI Side. The TI interface code is not able to overwrite the firmware, not even accidentally.

 

A quick technical note, skip if not interested in the technical parts - on startup the AVR code checks if the configuration area in EEPROM is blank, which it will be in this case. When it finds this, it does a basic initial configuration. This initial configuration was designed to activate a test program, but that test program isn't loaded anymore, so you'll just see a basic configuration in GROMCFG when you get there. Thus it is fine to not load any EEPROM data on a fresh chip.

 

When you boot it up, it will be completely blank, so in order to load any software you need access to a program loader. You can either use the Playground loader that was developed for XB27 (which runs from TI BASIC), or just hold space bar while turning on the console. This space bar recovery only works the first time you power on -- it does not work on reset (not even if you have a reset button!). This is just to minimize conflicts. (NOTE: this startup recovery is not yet implemented in Classic99). When you do this, you'll get two additional options added to the selection menu:

 

post-12959-0-30697900-1445140273_thumb.jpg

 

"EASY BUG" is the Easy Bug debugger from Mini-Memory (but the CS1 parts are removed). This may be useful to poke around a little bit. "RUN PROGRAM FILE" is the program image loader from Editor/Assembler, and can be used to run GROMCFG. (GROMCFG is also included in the archive. GROMLOAD is the loader-only version).

 

In most cases, if you're an end user, you hopefully just have a save dump from GROMCFG (such as the XB27 image), you can run GROMLOAD from your disk system and load the file.

 

GROMLOAD looks like this, just follow the prompts:

 

post-12959-0-64540400-1445141421_thumb.jpg

 

GROMCFG looks like this, consult the UberGROM manual:

 

post-12959-0-59809500-1445141469_thumb.jpg

 

A BIG WARNING: DO NOT RUN THESE PROGRAMS ON FINISHED, RELEASED CARTRIDGES. If you erase the settings or the GROM, the cartridge won't work anymore and you'll have to reload it. We had some trouble where GROMCFG was setting default parameters on launch without saying anything and people's XB27 stopped working -- there's no guarantee all such bugs are caught. Use this software only for making new cartridges or reloading/updating existing ones, not just to look around. :)

 

  • Like 7
Link to comment
Share on other sites

^ ^ ^

gallery_35324_1027_7598.jpg

 

This is a seriously great post Tursi! This information on how to use your totally unequaled GROMCFG & GROMLOAD programs a great asset to the community.

 

I should probably start a separate heading for things best used with GROMLOAD, agree?

 

Once Gazoo's images are posted in the .BIN repository thread, I'll be sure to link this thread, in the mean time I'm adding this one to my list of best threads.

Link to comment
Share on other sites

This cartridge board has two independent programming areas, @Willsy--one is the AVR, which provides a space for 120K GROM data (and even a little bit of additional GRAM), the other provides 512K of bank-switched ROM data. The 512K Red boards use the same 378 switching scheme as the ROM side of the UberGROM boards, so it is possible yo use either one for 512K ROM-only images (you can just leave the Atmel ATMega1284 off of the UberGROM board when using it this way).

  • Like 1
Link to comment
Share on other sites

This cartridge board has two independent programming areas, @Willsy--one is the AVR, which provides a space for 120K GROM data (and even a little bit of additional GRAM), the other provides 512K of bank-switched ROM data. The 512K Red boards use the same 378 switching scheme as the ROM side of the UberGROM boards, so it is possible yo use either one for 512K ROM-only images (you can just leave the Atmel ATMega1284 off of the UberGROM board when using it this way).

 

Thanks for the explanation. I must admit I haven't followed the UberGROM stuff at all, as my hobby time is quite limited and I've really had to be strict with myself. I've really been engrossed in Forth/TurboForth much too much!

 

So, the 512K of ROM space (and the GROM space, for that matter) is hosted in Flash memory, yes? Is it possible (via some contrived means) for the TI to write to flash pages somehow? (I'm thinking out cool options for storage of data in the flash memory, in addition to cartridge images).

Link to comment
Share on other sites

The 512k ROM chip is not writable from the TI side. The UberGROM is meant to be written from the TI side.

 

The UberGROM is not just GROM, though. It features:

 

120k of GROM (re-writable in system with GROMCFG or custom user code, 256 bytes at a time)

15k of GRAM

4k of "G"EEPROM (or Non-volatile GRAM if you like, writable by single bytes, though 260 bytes are used for configuration.)

4 General Purpose 5v Input/output pins, user-configurable

4 8-bit analog to digital inputs

1 high speed UART with 256 byte read and write buffers

1 continuously running 16-bit 7.8KHz timer

 

-all routed through a memory mapper that lets you assign all of the above any way you like through the primary 16 bases of GROM, with the only limit being they remain in cartridge space.

  • Like 3
Link to comment
Share on other sites

The 512K space on the UberGROM is Flash--however, no loader software has been written to support direct writing on the TI (there are jumpers on the board that would enable this if someone were to write such a loader though).

 

Ah, I was never sure if the jumpers were installed.... maybe you can publish the specification for how to talk to it, and we can try?

  • Like 1
Link to comment
Share on other sites

I was thinking of a software interface that would allow the TI to write to flash pages. At it's lowest level I guess it would work in a similar way to accessing the VDP: An address port and a data read and write port. Addition ports would be needed to set the flash page. In practice, you'd have to steal a few addresses from (probably) the end of the cart space. The microcontroller software would monitor for accesses in those areas and behave accordingly. Would (obviously) require additional software on the microcontroller side though.

 

I was thinking about things like a RAM disk for Forth, where the blocks themselves are hosted in flash on the chip, rather than on disk. No DSR would be needed, since a Forth block is 1024 contiguous bytes of memory. It would therefore be very easy to write them/read them to/from flash, as long as an interface existed to permit it. Sounds like it's not possible currently.

  • Like 1
Link to comment
Share on other sites

 

120k of GROM (re-writable in system with GROMCFG or custom user code, 256 bytes at a time)

15k of GRAM

 

4k of "G"EEPROM (or Non-volatile GRAM if you like, writable by single bytes, though 260 bytes are used for configuration.)

4 General Purpose 5v Input/output pins, user-configurable

4 8-bit analog to digital inputs

1 high speed UART with 256 byte read and write buffers

1 continuously running 16-bit 7.8KHz timer

 

Cool, I learn something new every day! I knew about the first two, I was unaware about the rest. I can see someday that all the good information in this thread might one day be plagiarized..., er make that 'compiled' into a neat primer on the Uber Cart.

 

I can envision...

A front section as an introduction with a photo labeling all the parts and their uses and or capabilities.

A section on how to set it up for use as an UberGROM

Another section with "follow along" instructions (and example) of how to use your TI software to program the UberGROM, with a possible You Tube link.

And lastly a section covering the technical aspects that most people never learn about.

Link to comment
Share on other sites

I was thinking of a software interface that would allow the TI to write to flash pages. At it's lowest level I guess it would work in a similar way to accessing the VDP: An address port and a data read and write port. Addition ports would be needed to set the flash page. In practice, you'd have to steal a few addresses from (probably) the end of the cart space. The microcontroller software would monitor for accesses in those areas and behave accordingly. Would (obviously) require additional software on the microcontroller side though.

 

I was thinking about things like a RAM disk for Forth, where the blocks themselves are hosted in flash on the chip, rather than on disk. No DSR would be needed, since a Forth block is 1024 contiguous bytes of memory. It would therefore be very easy to write them/read them to/from flash, as long as an interface existed to permit it. Sounds like it's not possible currently.

 

The microcontroller isn't fast enough to interface to the CPU side bus, you'd want an ARM level chip for that.

 

But Karsul says the interface is already there, so in theory no hacking is needed, only software. Let's wait and see.

 

That said, you can do that with GROM just as easily, why doesn't it work for that?

Link to comment
Share on other sites

 

Cool, I learn something new every day! I knew about the first two, I was unaware about the rest. I can see someday that all the good information in this thread might one day be plagiarized..., er make that 'compiled' into a neat primer on the Uber Cart.

 

I can envision...

A front section as an introduction with a photo labeling all the parts and their uses and or capabilities.

A section on how to set it up for use as an UberGROM

Another section with "follow along" instructions (and example) of how to use your TI software to program the UberGROM, with a possible You Tube link.

And lastly a section covering the technical aspects that most people never learn about.

 

Actually, you commented on the UART before, but that was before XB27. ;)

 

That's an interesting idea, though. I can certainly do a short write up on each peripheral and how to use it, given a few days between each one.

Edited by Tursi
  • Like 1
Link to comment
Share on other sites

 

Actually, you commented on the UART before, but that was before XB27. ;)

 

I can certainly do a short write up on each peripheral and how to use it, given a few days between each one.

 

 

Hmm, I did? I attribute my advancing decrepitude as the excuse for forgetting.

 

Excellent MEGA THANKS on the offer Tursi. It'll be great because there is nobody better than the author/inventor themselves!

Link to comment
Share on other sites

So one could write to grom/gram at (more or less) normal speeds?

 

I don't know what you define as a normal speed. But you can't write to any flash at the same speed as writing to RAM.

 

The AVR flash has 256 byte blocks. Each block access (either erase or write) takes from 3700uS to 4500uS. Each command is two bytes plus you also need to load the 256 bytes of data to be written (these are at normal GROM write speeds which is roughly 36 clocks per write or 12uS per write). The timing is all handled automatically by the MCU, you just write GROM.

 

The AM29F040 512K flash (if we get it working) has 64 kilobyte sectors (this is the minimum erase size). Sector erase normally takes 1 second, but can take up to 8s. Each byte is written with a 4 byte sequence at normal ROM speeds (4 clocks or 1.2uS), and that fourth byte takes from 7uS to 300uS to finish - you have to poll for it.

 

It's worth reminding though that flash memory is not infinitely writable - they are limited on the number of erases that are possible. Once the limit is reached, the memory will start to fail. So using flash as a temporary RAMdisk needs to be considered carefully. (Of course, for more permanent storage, like a Horizon RAMdisk, it's not bad at all!) The AVR supports 10,000 erase cycles while the AM29F040 supports 100,000. The main thing you want to do there is just to make sure you never re-write a block with the same data. Compare first, and just skip if it's the same. Rotating WHERE you write data is also helpful, this is what "wear leveling" is.

Link to comment
Share on other sites

 

The AM29F040 512K flash (if we get it working)...

 

Yeah, there is quite the program cycle disparity between the AT49F040 and the AM29F040. I wonder why, especially if they are essentially the same thing. I'm thinking the AMD people put a typo in their spec sheet as they list 1,000,000 cycles.. GUARANTEED! :)

 

Why do you mean *IF* you can get it working? What's up?

post-35324-0-83914400-1445373079_thumb.jpg

post-35324-0-28143400-1445373090_thumb.jpg

Link to comment
Share on other sites

It's worth reminding though that flash memory is not infinitely writable...

 

Indeed. However, since the cart contains 15K of GRAM, I think that's more than enough for what I was envisioning. I'd just use GRAM.

 

The only other problem I see is... Classic99 doesn't emulate any of this stuff ;) There's no way I could develop this on real iron. I'd rather nail my feet to the floor! :P

Link to comment
Share on other sites

 

Indeed. However, since the cart contains 15K of GRAM, I think that's more than enough for what I was envisioning. I'd just use GRAM.

 

The only other problem I see is... Classic99 doesn't emulate any of this stuff ;) There's no way I could develop this on real iron. I'd rather nail my feet to the floor! :P

 

It's emulated all this for years! The only thing that wasn't in the emulation (which I added two updates ago) was the ability to load "UberEEPROM" from the INI file, which was necessary to predefine cartridges. How do you think I developed the test program and the loader? ;) (And it also doesn't emulate the recovery startup mode, but you don't need that for development).

 

Now, the downside is that the debugger doesn't handle any of it... but stepping through code still helps a lot. :)

 

As for the usage, if ALL you want is the GRAM, let's select a different AVR for you. The 1284P is massive overkill if you don't need all the flash memory. :)

Link to comment
Share on other sites

Here's the schematic for the UberGROM, Tursi. The relevant jumpers are JP-1 (Write Enable, normally 1-2 to disable, switch to 1-3 to enable) and JP-3 (Output Enable, normally 1-2, pulled to Ground, but would be 1-3 here). One note, I think you need to be able to toggle the OE signal during reprogramming, so you would need to run a wire from pin 3 to whatever spare pin you're using to do the toggling.

512K UberGROM-4 (Final).pdf

  • Like 5
Link to comment
Share on other sites

 

It's emulated all this for years! The only thing that wasn't in the emulation (which I added two updates ago) was the ability to load "UberEEPROM" from the INI file, which was necessary to predefine cartridges. How do you think I developed the test program and the loader? ;) (And it also doesn't emulate the recovery startup mode, but you don't need that for development).

 

I shall go and sit in the corner with a big dunces hat on :-) :dunce: Seriously though, it's great that Classic99 does this. Please forgive me not keeping up - I've really kind of ignored all this UberGROM stuff until now, so I'm seriously playing catch-up.

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...