512K Cartridge Status

[Gazoo]

I actually have to go through the thread and take all of the lessons learned and input them into the document. There won't be a true final version until Tursi has sufficient free time to code the rest of the loader he's been working on for the GROM side. Other than that, though, the manual will be pretty much done once I put the tweaks from this thread into it.

 

 

'What a long strange trip it's been'

 

Gaz

[+Ksarul]

I've finished asembling five of the new boards and should have the other six that are in mostly-complete form done by tomorrow.

 

And you are right about the long, strange trip, Gazoo! It took almost five years for this idea to go from germination to fully-functional, fun product.

[Imperious]

I will be interested in a UberGrom board at some point for sure but have a few questions

 

1. Any idea of a price?

2. Will it be end user programmable?, I do have a eprom burner

3. Will I be able to order a blank pcb and build it myself?

[Gazoo]

Ubergrom question, probably best answered by Tursi. (as he's probably the only one that can answer it!)

 

Exactly how does one access the 15k of Gram memory in the 1284p? I've been over the docs a number of times and don't see a way to map it in in the EEprom space.

Apparently the first nybble should be >0, but how does one come up with the second nybble if they are all used up for the 128k flash (>0 through >F)?

 

I must be missing something.

 

Gazoo

Edited September 19, 2014 by Gazoo

[Tursi]

If you are using GROM paging (ie: different GROM bases, 9800, 9804, etc - which I am pretty sure you are!), there aren't enough devices in the UberGROM to use up all the slots (16 pages and 5 GROMs per page makes 80 slots, although the very last one is half reserved for the permanent configuration space. 120k of GROM is only 15 slots (120/8), so you should have lots left.)

 

You are correct that the first nibble is >0 to indicate RAM. the second nibble is which page of RAM. Remember that the way the map in EEPROM works, the location that you write the byte to determines where in the TI's memory it appears. The first nibble is the device type, and the second is the device page. The >0 - >F you are specifying for GROM is which GROM page you're mapping.

 

In the case of RAM, there are only two pages, >0 and >1 (with the second page not being a full 8k).

 

The way that the EEPROM is laid out is that there are two bytes of configuration at >0000 and >0001. After that, the next 256 bytes are the mapper configuration. (If you disable banking, then only the next 16 bytes). This allows configuration for 16 pages of GROM (9800, 9804, 9808, 980C, 9810, 9814, 9818, 981C, 9820, 9824, 9828, 982C, 9830, 9834, 9838, 983C).

 

Within each 16 byte configuration space are 8 bytes of map configuration, and 8 bytes of confirmation (bitwise inversion of the first 8 bytes used to detect bad writes and failing EEPROM).

 

I know it really needs a good drawing to be clear, but the simplest explanation is probably a list:

 

EEPROM - Configures TI Address

>0000 - no address, contains configuration bitflags (>01 - enable GROM bases, >02 - disable recovery program, >04 - allow rollover, remainder undefined)

>0001 - bitwise inversion of the data at >0000, if it doesn't match a default config is used.

 

>0002 - contains the configuration for GROM >0000 on base >9800 *

>0003 - contains the configuration for GROM >2000 on base >9800 *

>0004 - contains the configuration for GROM >4000 on base >9800 *

>0005 - contains the configuration for GROM >6000 on base >9800

>0006 - contains the configuration for GROM >8000 on base >9800

>0007 - contains the configuration for GROM >A000 on base >9800

>0008 - contains the configuration for GROM >C000 on base >9800

>0009 - contains the configuration for GROM >E000 on base >9800

>000A - contains the bitwise inverted value of >0002 to indicate valid

>000B - contains the bitwise inverted value of >0003 to indicate valid

>000C - contains the bitwise inverted value of >0004 to indicate valid

>000D - contains the bitwise inverted value of >0005 to indicate valid

>000E - contains the bitwise inverted value of >0006 to indicate valid

>000F - contains the bitwise inverted value of >0007 to indicate valid

>0010 - contains the bitwise inverted value of >0008 to indicate valid

>0011 - contains the bitwise inverted value of >0009 to indicate valid

 

>0012 - contains the configuration for GROM >0000 on base >9804 *

>0013 - contains the configuration for GROM >2000 on base >9804 *

>0014 - contains the configuration for GROM >4000 on base >9804 *

>0015 - contains the configuration for GROM >6000 on base >9804

>0016 - contains the configuration for GROM >8000 on base >9804

>0017 - contains the configuration for GROM >A000 on base >9804

>0018 - contains the configuration for GROM >C000 on base >9804

>0019 - contains the configuration for GROM >E000 on base >9804

>001A - contains the bitwise inverted value of >0012 to indicate valid

>001B - contains the bitwise inverted value of >0013 to indicate valid

>001C - contains the bitwise inverted value of >0014 to indicate valid

>001D - contains the bitwise inverted value of >0015 to indicate valid

>001E - contains the bitwise inverted value of >0016 to indicate valid

>001F - contains the bitwise inverted value of >0017 to indicate valid

>0020 - contains the bitwise inverted value of >0018 to indicate valid

>0021 - contains the bitwise inverted value of >0019 to indicate valid

 

>0022 - contains the configuration for GROM >0000 on base >9808 *

>0023 - contains the configuration for GROM >2000 on base >9808 *

>0024 - contains the configuration for GROM >4000 on base >9808 *

>0025 - contains the configuration for GROM >6000 on base >9808

>0026 - contains the configuration for GROM >8000 on base >9808

>0027 - contains the configuration for GROM >A000 on base >9808

>0028 - contains the configuration for GROM >C000 on base >9808

>0029 - contains the configuration for GROM >E000 on base >9808

>002A - contains the bitwise inverted value of >0022 to indicate valid

>002B - contains the bitwise inverted value of >0023 to indicate valid

>002C - contains the bitwise inverted value of >0024 to indicate valid

>002D - contains the bitwise inverted value of >0025 to indicate valid

>002E - contains the bitwise inverted value of >0026 to indicate valid

>002F - contains the bitwise inverted value of >0027 to indicate valid

>0030 - contains the bitwise inverted value of >0028 to indicate valid

>0031 - contains the bitwise inverted value of >0029 to indicate valid

 

... and so on, through to the configuration for base >983C. Sorry for spelling out such a repetitive list, but I wasn't sure how else to explain it.

 

So, you can literally put any block of memory or Uber GROM peripheral at any of the supported TI addresses just by dropping it's setting in the right place in EEPROM. You can also mirror blocks or devices or the like in the same way.

 

*- the gotcha is that the current version of the GROM code does not respond at console addresses, even if you configure it. I left the space for future work (mostly my MPD).. The other gotcha is that the very last slot in the system (GROM address >E000 at base >983C) only has 6k available, the last 2k are reserved for the configuration EEPROM space (even if GROM banking is disabled, you can still read it here!)

[Tursi]

I will be interested in a UberGrom board at some point for sure but have a few questions

 

1. Any idea of a price?

2. Will it be end user programmable?, I do have a eprom burner

3. Will I be able to order a blank pcb and build it myself?

 

 

I can't answer the first or third question, but I can answer the second. There are two parts to the board - a ROM, and a GROM. The ROM will require an EPROM burner to program. The GROM I'm intending to be programmable in the TI, but a few people are already testing the code by programming the AVR directly out of circuit.

[Imperious]

Thanks for the reply. Definitely one to look forward to..

[Gazoo]

If you are using GROM paging (ie: different GROM bases, 9800, 9804, etc - which I am pretty sure you are!), there aren't enough devices in the UberGROM to use up all the slots (16 pages and 5 GROMs per page makes 80 slots, although the very last one is half reserved for the permanent configuration space. 120k of GROM is only 15 slots (120/8), so you should have lots left.)

 

You are correct that the first nibble is >0 to indicate RAM. the second nibble is which page of RAM. Remember that the way the map in EEPROM works, the location that you write the byte to determines where in the TI's memory it appears. The first nibble is the device type, and the second is the device page. The >0 - >F you are specifying for GROM is which GROM page you're mapping.

 

In the case of RAM, there are only two pages, >0 and >1 (with the second page not being a full 8k).

 

<snip>

 

Thanks! Now I understand the need for the inverted bytes, too. Without them, all those >00 banks would be mapped to Gram page >0.

 

Gazoo

[Gazoo]

Update on the MiniPro programmer, it CAN program 1284p chips!

 

First select the correct IC to be programmed (upper right corner), click the config tab on the far right, and clear all the check boxes for the fuses and lock bits as in the screenshot below.

 

 

Now click device, then click program. Set only the two checkboxes as in the screenshot below and click program.

It should do so without error. Click cancel to return to main screen.

 

 

Now go back to the config tab and set the checkboxes for the fuses like the example below.

 

 

Click the code memo tab and then click the file tab and open to load the 128k flash file (must be a .bin file).

Click the data memo tab and then click the file tab and open to load the EEprom file (must be a .bin file).

Now click device and then program.

Set all the checkboxes as in the example below. and click program. You will get an error when it programs the fuses (the last part), but it will have successfully programmed them.

 

 

Click cancel to exit.

 

Your 1284p chip is now programmed!

 

Gazoo

 

 

[+Ksarul]

Nice. I think I need to add this tutorial to the manual, Gazoo!

[Gazoo]

I had to figure out how to make it work as my MRP01 died this morning while I was attempting to upgrade my personal XB v2.7 cart.

It's actually much faster than using Atmel Studio.

 

Gazoo

[UKRetrogamer]

The above will prove very useful as I'm awaiting the arrival of a minipro programmer from eBay and I've yet to attempt programming the cartridge boards I received from Ksarul a couple of months ago.

[UKRetrogamer]

Gazoo, in a previous post (which I can't locate) you mentioned the ATMEL devices are one-time programmable. Now you know how to program theses on the minipro, is this still the case?

 

In the past, I've set the fuses incorrectly on an AT328P using an ISP and been unable to recover the device as I couldn't work out the clock-frequency required to reprogram it.

 

Since receiving it, I've duplicated a programmed 328 with the minipro but omitted to set the fuses, making it effectively "read-only" when placed back into an Arduino board. I recovered this one by copying from a second 328 which had the fuses set correctly.

 

This leads me to wonder if the minipro will still overwrite the ATMega series, even if their fuse settings is in an unknown state.

[Gazoo]

Gazoo, in a previous post (which I can't locate) you mentioned the ATMEL devices are one-time programmable. Now you know how to program theses on the minipro, is this still the case?

 

In the past, I've set the fuses incorrectly on an AT328P using an ISP and been unable to recover the device as I couldn't work out the clock-frequency required to reprogram it.

 

Since receiving it, I've duplicated a programmed 328 with the minipro but omitted to set the fuses, making it effectively "read-only" when placed back into an Arduino board. I recovered this one by copying from a second 328 which had the fuses set correctly.

 

This leads me to wonder if the minipro will still overwrite the ATMega series, even if their fuse settings is in an unknown state.

 

No, they're not one time programmable. If you follow the directions in this post

http://atariage.com/forums/topic/193163-512k-cartridge-status/page-21#entry3080813

you will be able to reprogram a 1284P. From my experiments, you can only program the code memory and data memory sections if you first uncheck all the boxes in the config (fuses and lock bits) section and reprogram only the the config section. Setting up a project file for these 2 steps makes things much easier.

 

Gazoo

 

Edited October 12, 2014 by Gazoo

[UKRetrogamer]

I'm still getting the hang of the minipro but I've already worked out saving a Project will store the compete code, data and config/fuse areas (create a backup, if you will) of a complete chip whereas the File/Save menu only stores the data currently on-screen.

 

Restoring a project saved from a working Arduino is how I unlocked the read-only ATMega328 I inadvertently created, mentioned in my previous post.

 

Using the minipro, I've picked up a habit early of reading a chip then saving a project from the complete data before I try to re-write _anything_.

 

Using the Atmel AVRISP MKII (my previous method of programming Atmel ICs), you'd need to know the clock frequency set by the fuses and provide a suitable oscillator. Something which (I assume) could prove difficult if the state of the fuses are unknown.

[Gazoo]

<snip>

Using the Atmel AVRISP MKII (my previous method of programming Atmel ICs), you'd need to know the clock frequency set by the fuses and provide a suitable oscillator. Something which (I assume) could prove difficult if the state of the fuses are unknown.

 

I never used an oscillator and managed to use it ok, you just need to angle the chip and only connect the first half of the pins when you're setting the fuses as described by Arcadeshopper.

 

Gazoo

[Imperious]

I have a bunch of the 64k Jon Guidry boards, no components fitted yet, and am wondering if it is possible to modify them into a 512k board with a LS378 instead of the 379.

 

I can't find schematics of the 512k board, but could figure it out myself if they are available.

Edited December 23, 2014 by Imperious

[+Lee Stewart]

I have a bunch of the 64k Jon Guidry boards, no components fitted yet, and am wondering if it is possible to modify them into a 512k board with a LS378 instead of the 379.

 

I can't find schematics of the 512k board, but could figure it out myself if they are available.

 

Maybe you already know all of this; but, for one thing, the 64KB board uses the 379 (quad latch) with its inverted outputs and a 378 (hex latch) does not have inverted outputs—so the boards are wired differently in that regard. A 378 has the same number of pins, but not one of the latch I/O pins are in the same place. Furthermore, the larger capacity EPROMs have 32 pins vs. the 28 of the 64KB (and lower) chips. You'll be doing quite a lot of surgery on a 64KB board to convert it to 512KB capacity, I should think.

 

...lee

[+Ksarul]

It is possible to modify the 64K boards to the 128Kx4 configuration (equivalent to the Black boards), as Acadiel hacked one to build the first of those shortly after the 64K boards came out. I believe he still has the pictures/instructions up on his Hexbus site. Trying to modify one of them to use in the 512K mode would be a truly ugly hack, as most of the traces connecting to the 379 are wrong when using a 378. Tursi did a 379 to 378 hack on one of the early UberGROM boards (the first iteration used 379s, as I hadn't discovered the added functionality of the 378s yet). The growth on top of the socket was about as neat as you could make it, and it still looked like something out of Frankenstein's lab. That said, I think he only connected the first four latches, as he wasn't trying for use of the full 512K (the 128K that you get with four latches was enough for his test code). I have schematics for the 512k board and for the UberGROM, although I think I still need to do some finishing touches on the one for the 512K board.

[+acadiel]

I have a bunch of the 64k Jon Guidry boards, no components fitted yet, and am wondering if it is possible to modify them into a 512k board with a LS378 instead of the 379.

 

I can't find schematics of the 512k board, but could figure it out myself if they are available.

 

Like the others have said, you can pretty easily modify them into 128K boards by adding the last latch in/out (a couple of wires) and cutting a trace or two. Fred did a great job documenting it here: http://home.vodafonethuis.nl/fgkaal/Modules/mod_mm2010.html#megamod_2010

 

You can also do what Ksarul mentions above to make it 512K switched... the relevant pictures on my site are:

 

http://hexbus.com/TI-99_4A_Home_Computer_Page/Hardware_Projects.html#37

http://hexbus.com/TI-99_4A_Home_Computer_Page/Hardware_Projects.html#38

 

It's an ugly hack, but it'll work.

[Imperious]

Thanks for all the replies everyone.

 

I think all the boards out there need to be referred to the same way, bits or bytes only, as some cart boards are referred to differently.

I should have been a bit clearer about that in the 1st place obviously.

 

What I was wondering is if the 64k byte boards I have can be modified into 512k byte boards, as in the non Grom board.

 

Considering that the Game carts that are using the 512k byte rom only binaries have been posted, I thought modifying my 64k byte boards wouldn't be a bad idea, rats nest wiring

mess included.

 

Ksarul it would be fantastic if You could post the schematic for the 512k byte boards later when they are sorted.

[+Lee Stewart]

... I think all the boards out there need to be referred to the same way, bits or bytes only, as some cart boards are referred to differently. ...

 

I did not check all the posts in this thread, but I think everyone means bytes when describing the boards as 16k, 64k, 512k etc. From habit, I have most often used ‘K’ to stand for “kilo” when talking about bits and bytes, even though ‘k’ is the official SI abbreviation for “kilo”. But, then, the SI says that referring to 2¹⁰ bits as 1 kilobit is improper and none of us is going to change how we refer to that when it comes to computers. I think we all abbreviate bytes as ‘B’ and bits as ‘b’ so that ‘KB’ and ‘kB’ both mean “kilobytes” while ‘Kb’ and ‘kb’ both mean “kilobits”.

 

I am sure some are confused when they hear talk about the chips and the boards in the same breath, however, because the names of the chips refer to the chip size in bits, e.g., 27C256 is a 256kb EPROM, which I am using to get 32kB on either the 64kB or the 512kB board, the latter being this thread’s topic.

 

Sorry about the digression. I also may have missed your point.

 

...lee

[+Ksarul]

As both Acadiel and I have noted, it is very easy to modify your 64K boards into 128K boards, and only slightly more difficult to modify them into boards that give you four 128K banking zones using a pair of switches (for a total of 512K--although not in a form that the 512K images posted here support, as the 64K boards are Inverted (there are tools already out there to reverse images, and I do have some built that way here at home) and they expect the whole 512K to be present in one banking zone, which is not the case here). This method is not too ugly.

 

To modify it to use the 378 banking, you will have to do one of two things--cut a lot of traces and run a bunch of extra wires (the 512K board has a LOT more jumpers, although a number of them are the same as the ones on the 64K board) or cut a smaller number of traces and run wires from each leg of the 378 to the appropriate pin in the socket. You'll still have to run some wired directly from the 378 to the EPROM to create the address lines and pins that are not present (four of them, but only three are used by the 512K board--the fourth one and some additional components are needed to do a 1024K hack to the board, making it into two 512K banking zones).

 

I'll try and put the schematic up soon. I should have it finished in the next week or two, as I don't have physical access to the machine it is on until after the New Year.

[Lisias]

Well if it has been done once, it can be done twice. Not saying it will be easy. However the UCSD Pascal is built in a very modular fashion. Thierry has an excellent article http://nouspikel.group.shef.ac.uk/ti99/pcode.htm

 

 

Hi.

 

This is just to pinpoint the new location for the this site:

 

http://www.unige.ch/medecine/nouspikel/ti99/titechpages.htm

 

In special, the pcode article is now here : http://www.unige.ch/medecine/nouspikel/ti99/pcode.htm

 

(edit: see post below for the correct URLs that will always pinpoint to the currently used page host)

Edited December 28, 2014 by Lisias

[+Lee Stewart]

 

Hi.

 

This is just to pinpoint the new location for the this site:

 

http://www.unige.ch/medecine/nouspikel/ti99/titechpages.htm

 

In special, the pcode article is now here : http://www.unige.ch/medecine/nouspikel/ti99/pcode.htm

 

 

 

These links should use Thierry’s domain name (http://www.nouspikel.com) so that, when he moves again, it will resolve to the new server:

• TI home page: http://www.nouspikel.com/ti99/titechpages.htm
• p-code article: http://www.nouspikel.com/ti99/pcode.htm

...lee