Jump to content
IGNORED

512K Cartridge Status


Ksarul

Recommended Posts

I just checked. 100 boards cost about $570; 250 boards cost about $1,050; and 500 boards would be just shy of $1,800. Somewhat more expensive than the last runs we did, but not significantly so. On any quantity less than 100, the largest part of the cost is setup, as that is a fixed fee of $245. Everything else is variable, based on the quantity ordered.

 

I think I still have about 20 bare boards from the test batch I did.

 

We can do ExpressPCB again.. but I'm all for getting them made by someone like ACC. That was so much a time saver - they even put them in ASD bubble wrap :) Well worth the few bucks having them assembled vs making folks have to solder them, and plus the part picking/packing time.

 

I did have to put in my own 74LS379's into 250 of those suckers before they bagged them though... that way they could "release" them to me as RoHS compliant.

Link to comment
Share on other sites

Agreed, Jon. That would be a better route. I just wanted to get the low-end pricing data identified. We'd just have to do the same thing with the '378s on this one that you did with the '379s. At least I have more than enough of the 512K chips. We could do 2,000 plus cartridges before I run out of them. . .and I really don't think we'd ever need to do that many (but one never knows!).

Link to comment
Share on other sites

Im in for a couple. :) is there going to be a minimum order for the masses? Depending on final price, I'd definitely like to place some kind of order.

 

I'll need to read up some more on this board... I know it's a beast, but im afraid I don't know all the details. :)

Link to comment
Share on other sites

Note that the source you quote is in Taiwan. I've had some dealings with this seller before (I bought a bunch of keyswitches from them), and no issues, but chips from Taiwan and China are often not what they seem (and sometimes that is no fault of the seller's as they bought them on the local market as overstock). That said, the chips cost .68 each from Unicorn Electronics (shipped). A higher price, but they are guaranteed NOS chips.

Link to comment
Share on other sites

I found a US seller that had a few hundred of the Motorola '378s for sale, so I bought 300 of them for $108, shipped. That actually works out to being even better than the price you found Jon. Now I'm sure we'll have enough of them to build about as many of the carts as we will need. . . :) many thanks for your inputs too, as it keeps my mind actively looking for improvements for the project! :)

  • Like 2
Link to comment
Share on other sites

I'm sure this info has been posted before, but how many pages of Grom will be in the Grom section of the cart?

To clarify, how many Grom bases will be available? Grom memory from g>6000 to g>FFFF specifically, as it makes sense to

have g>0000 to g>5FFF the same on each page. The Rom area is interesting as I plan on loading it up with Memory image files

(other than the first two banks needed for the XB v2.7 Rom) and using it as a Romdisk (did I coin a new term?) which will move the necessary data from Rom to Ram using the GPL Move code. Sort of like an HSGPL+Ramdisk in a cart - FUN!

 

Gazoo

Edited by Gazoo
Link to comment
Share on other sites

The GROM is designed to only run from >6000 to >FFFF (ie: the cartridge space), you can not override GROM 0, 1 or 2 with it as released. (The ambitious can see in the code how to change that and make their own, but I don't want it to conflict with my MPD when I release that.)

 

So that is 5 GROM slots. But because it supports 16 GROM bases, that gives you 80 slots to load functions into. There are 15 slot worth of GROM data, which each slot being the full 8k (120k total). Then there are 2 slots of RAM, 1 of EEPROM, 1 of GPIO, 4 of ADC, 1 of timer, and 1 of UART, meaning to map all possible features takes 26 slots. This means you have lots of flexibility in how you lay it out.

Link to comment
Share on other sites

The GROM is designed to only run from >6000 to >FFFF (ie: the cartridge space), you can not override GROM 0, 1 or 2 with it as released. (The ambitious can see in the code how to change that and make their own, but I don't want it to conflict with my MPD when I release that.)

 

So that is 5 GROM slots. But because it supports 16 GROM bases, that gives you 80 slots to load functions into. There are 15 slot worth of GROM data, which each slot being the full 8k (120k total). Then there are 2 slots of RAM, 1 of EEPROM, 1 of GPIO, 4 of ADC, 1 of timer, and 1 of UART, meaning to map all possible features takes 26 slots. This means you have lots of flexibility in how you lay it out.

 

That's just a little confusing. :) As best as I can figure from the info, the answer to my question is 3 pages. >6000 to >FFFF is 40k, and 40k x 3 = 120k.

So I'll have 3 pages of grom from >6000 to >FFFF, and I assume they'll respond to >9800, >9804, & >9808? So it's sort of like a Pgram+, but with only 3 pages instead of 4?

 

Gazoo

Link to comment
Share on other sites

I all 16 of the GROM pages of the 16 pages (>6000->FFFF) is used that is 8x5=40K so 40Kx16Pages=640K of GROM any TI99/4A can address.

 

I do not know exactly what a Slot is as what is being discussed. I always thought a Slot was just the one in the TI Console.

 

For example you can slide a GRAM KRACKER or GRAMULATOR with only 2 pages of GROM in that slot. But the PGRAM had 4 Pages of GROM.

Link to comment
Share on other sites

I think the confusion comes from definition here... I do not know what you are classifying as a "page", that's why I used my own terms and defined them.

 

A GROM "slot", in my terminology, is 8k.

 

There are 16 GROM access bases, which you can think of as 16 completely distinct ranges from >6000 to >FFFF.

 

In that range, each 8k is a "slot", so there are 5 "slots" in each access base. This is important, because GROM memory is NOT a continuous memory range from >6000 to >FFFF. It is a range from >6000 to >7FFF, then one from >8000 to >9FFF, then one from >A000 to >BFFF, then >C000 to >DFFF, and finally >E000 to >FFFF. If you try to read memory from a GROM and try to roll over from >7FFF to >8000, it actually wraps back around to >6000 - the high three address bits never autoincrement. Software that uses more than one GROM actually has to use a jump instruction to change chips. :)

 

So 5 possible slots, and 16 possible bases, means there are a total of 80 slots.

 

You can configure each slot to be any available block of memory or a peripheral. It is not mandatory to fill every slot.

 

So, you /can/ configure it as you describe. But you don't HAVE to. For instance, if you want to load 3 different 6k GROM cartridges, they all expect to load at >6000. So you put one at >6000 in base >9800, one at >6000 in base >9804, and one at >6000 in base >9808. You have used 24k (because my device always allocates 8k blocks), but used three distinct bases. You have just left most of it (the slots from >8000-FFFF in each base) unmapped - there is nothing there.

 

If you are not familiar with how memory mappers work, the concept is admittedly a bit confusing. it should be more straightforward when the GUI exists so I can show you instead of talking theory. :)

Link to comment
Share on other sites

I do not know exactly what a Slot is as what is being discussed. I always thought a Slot was just the one in the TI Console.

 

We are talking specifically about my chip, Rich. I needed a term for each possible GROM location (combination of base and address) and chose 'slot'.

Link to comment
Share on other sites

I think the confusion comes from definition here... I do not know what you are classifying as a "page", that's why I used my own terms and defined them.

 

A GROM "slot", in my terminology, is 8k.

 

There are 16 GROM access bases, which you can think of as 16 completely distinct ranges from >6000 to >FFFF.

 

In that range, each 8k is a "slot", so there are 5 "slots" in each access base. This is important, because GROM memory is NOT a continuous memory range from >6000 to >FFFF. It is a range from >6000 to >7FFF, then one from >8000 to >9FFF, then one from >A000 to >BFFF, then >C000 to >DFFF, and finally >E000 to >FFFF. If you try to read memory from a GROM and try to roll over from >7FFF to >8000, it actually wraps back around to >6000 - the high three address bits never autoincrement. Software that uses more than one GROM actually has to use a jump instruction to change chips. :)

 

So 5 possible slots, and 16 possible bases, means there are a total of 80 slots.

 

You can configure each slot to be any available block of memory or a peripheral. It is not mandatory to fill every slot.

 

So, you /can/ configure it as you describe. But you don't HAVE to. For instance, if you want to load 3 different 6k GROM cartridges, they all expect to load at >6000. So you put one at >6000 in base >9800, one at >6000 in base >9804, and one at >6000 in base >9808. You have used 24k (because my device always allocates 8k blocks), but used three distinct bases. You have just left most of it (the slots from >8000-FFFF in each base) unmapped - there is nothing there.

 

If you are not familiar with how memory mappers work, the concept is admittedly a bit confusing. it should be more straightforward when the GUI exists so I can show you instead of talking theory. :)

 

GROM does not expect to load at >6000 as some Carts load at >E000 or >C000 so I do not understand that statement?

Miller Graphics referred to each address page as the 16 Pages. (You call them bases) And Miller Graphics call them Banks (you call them slots) and there are 5 Banks per Page.

So 16 bases with 5 slots was defined by Miller Graphics long ago as 16 pages with 5 banks. (potato pataato)

Now hardware wise yes TI did only use 6K as that was the only size chips they had at the time to do this. Miller Graphics expanded it to 8K for a good reason. 6K is just stupid.

Link to comment
Share on other sites

GROM does not expect to load at >6000 as some Carts load at >E000 or >C000 so I do not understand that statement?

 

it was an example. Lots of GROM cartridges are larger than 6k, too. But if you have a GROM program that expects to load at >6000, it often will not work at >E000.

 

Miller Graphics referred to each address page as the 16 Pages. (You call them bases) And Miller Graphics call them Banks (you call them slots) and there are 5 Banks per Page.

So 16 bases with 5 slots was defined by Miller Graphics long ago as 16 pages with 5 banks. (potato pataato)

Now hardware wise yes TI did only use 6K as that was the only size chips they had at the time to do this. Miller Graphics expanded it to 8K for a good reason. 6K is just stupid.

 

Terminology is confusing in this case, that is why I am defining my units. I got 'bases' from TI docs (I thought) that called each access address a GROM base. 'Slot' I invented as a term for both parts together.

 

I wasn't aware of the old terminology, but now we have a mapping. :)

Link to comment
Share on other sites

I'd like to be on the list buy 1 or 2 of these when available!

 

Can I put my XB or Compiled games on the cart? Do you need to something special?

I know it is not a "flash" cart. But just wondering....

 

Thanks,

Gene

 

It's possible to add menu entries to Extended Basic instead of the one entry for "DSK1.LOAD". I have 4 additional menu entries for XB programs in my personal version of XB v2.7 that I use with an HSGPL card. The data is stored in the additional ROM area of the card and a small DSR added so XB can find and load the program.

 

I'm assuming the cart will be similar enough to the HSGPL to use the same process, but I don't have very much info about it yet to guarantee that fact.

 

 

Gazoo

Link to comment
Share on other sites

It's possible to add menu entries to Extended Basic instead of the one entry for "DSK1.LOAD". I have 4 additional menu entries for XB programs in my personal version of XB v2.7 that I use with an HSGPL card. The data is stored in the additional ROM area of the card and a small DSR added so XB can find and load the program.

 

I'm assuming the cart will be similar enough to the HSGPL to use the same process, but I don't have very much info about it yet to guarantee that fact.

 

 

Gazoo

 

I'm familiar with the ROM side... it'll be simply 64 x 8K banks, accessible by writing to >6000 to >607E. It's a 49F040 flash chip, PLCC form factor. Ksarul bought a boatload of 49F040's and 74LS378's for us, so divvied up they will be only add a small amount to the total price. User programmable by any modern EEPROM programmer that can handle a PLCC chip (or a DIP programmer with a PLCC adapter. Don't skimp... the eBay budget ones are really sucky!)

 

We decided to non invert this time, we're using a 74LS378 instead of a 74LS379. 6 lines to toggle, I believe, address lines A9 to A14. The manual will have a nice chart about which address lines related to which bank to write to, and also list the bank number.

 

Typical power up behavior is the lowest bank. I'll verify with Ksarul's batch of 74LS378's when he gets them in that this is the case still. (It isn't guaranteed, so typically, we put bank switch coding the explicitly can switch to the first bank, i.e. for copying to 32K, etc.)

 

All that is needed to take current carts that have been made with 128K/256K/512K EPROMs on the inverted 74LS379 boards is simply invert all the 8K banks. Yep, just swap them out from TOP->BOTTOM to BOTTOM->TOP. Write it, and you have a working EEPROM With this new board.

 

(Note that the only 128K ROM that I'm aware of is F. G. Kaal's Megamod 2010. The only 512K ROM I'm aware of is a multicart image that Tursi and I got working.)

 

You can duplicate a 128K EEPROM four times in the 512K chips just for kicks and grins. Or a 16K program thirty two times. Whatever floats your boat... if the program is written correctly, it shouldn't matter that it only used 16K out of the 512K. :) Note that in the case of XB (where only half of the 8K is banked on a write to ROM), we can simply write the whole 8K again with the part of the 4K that it's expecting as well as the static other 4K of ROM. We didn't implement 4K switching with this design.

Link to comment
Share on other sites

  • 2 weeks later...

I was wondering if the cartridge could host UCSD Pascal. Combined with NANOPEB / CF7+ that would make a nice dev environment.

Heard that at one time there was a hacked version here in Germany that worked with a GRAM Kracker or similar device. Suppose its probably the ROM in the DSR space that would need some modification.

Link to comment
Share on other sites

I was wondering if the cartridge could host UCSD Pascal. Combined with NANOPEB / CF7+ that would make a nice dev environment.

Heard that at one time there was a hacked version here in Germany that worked with a GRAM Kracker or similar device. Suppose its probably the ROM in the DSR space that would need some modification.

 

I've seen that particular hack. I even had it loaded into the cartridge space on my Geneve at the TI Treff in Berlin many years ago. It worked great and also included a UNIT for the APPLESOFT routines. The hack was done by a programmer in Vienna, Austria. He sent it to the Treff with Alexander Hulpke so that it could be demonstrated (and tested on a Geneve). He was under strict instructions not to let anyone keep a copy of the application, as he was a beta tester and the author wanted to release it commercially. Unfortunately, it was neither released as a commercial product nor was it released into general availability. It is remotely possible that Alexander still has a copy--or that he can identify the original programmer to allow the hunt to continue in that direction.

Link to comment
Share on other sites

 

 

I've seen that particular hack. I even had it loaded into the cartridge space on my Geneve at the TI Treff in Berlin many years ago. It worked great and also included a UNIT for the APPLESOFT routines. The hack was done by a programmer in Vienna, Austria. He sent it to the Treff with Alexander Hulpke so that it could be demonstrated (and tested on a Geneve). He was under strict instructions not to let anyone keep a copy of the application, as he was a beta tester and the author wanted to release it commercially. Unfortunately, it was neither released as a commercial product nor was it released into general availability. It is remotely possible that Alexander still has a copy--or that he can identify the original programmer to allow the hunt to continue in that direction.

 

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

 

Basically the ROM in the p-code card must be patched to run from the cartridge space. The 12k roms (4k + 8k) could be put in 8k + 8k. Besides realigning the code to run from >6000 instead of >4000 and >5000 and doing the proper bankswitching (pcode card uses CRU for selecting the ROM) one must also change the adresses the GROMs respond to. In the pcode card the GROMS respond to >5xxxx adresses where the normal GROMs respond to >98xx I suppose.

Do not have access to MESS or classic99 but it would be interesting to takea further look at this.

As said due to the very modular fashion of the UCSD pascal system I do not believe it would be that hard. The ROM basically contains code to interface UCSD Pascal with the host OS.

 

It is beyond me why TI made a peripheral expansion card instead of putting it on a cartridge. Probably because of the 8 GROMS I suppose. I think it would have made UCSD Pascal more popular on the TI. Well it was next to impossible to obtain the p-code card in europe back in the days. Not in Belgium anyway. I'll stop hijacking the thread now :-)

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

  • 6 months later...

Well, I replied to this topic this AM, but looks like my reply got deleted. Here's the gist of what I put into it earlier:

 

Rasmus, above, makes up a good point. This is supposed to be a topic for the status for the 512K cartridge. I have been in contact with a moderator to get the assembly stuff put into its own thread. The GROM Discussion is now here: http://atariage.com/forums/topic/221144-grom-paging-discussion/

 

Please try and keep this thread constrained around the 512K cartridge itself, and the status of it. Debates about assembly, GPL, etc, should be put into another thread. I love all of you folks; please, be nice to one another and respect that we have many awesome people in this community. More than one person can be right about a topic, and I'd ask that we all respect that. If we try something, and it doesn't work, we can always try something else. We've had 30+ years to mess around with this system, so what's wrong with trying something new, failing, and adjusting our tactics? No need to get mad at each other, point fingers, etc.

Edited by acadiel
Link to comment
Share on other sites

Hi, all.

 

It is still in development. Currently, Tursi is debugging a possible power issue we saw during the Faire. The ROM part of the board is working ok, and the manual is mostly complete. Tursi has also written some pretty nice software to program the ATMega.

 

As this is a volunteer effort, it is slow going and in our spare time. If you are interested, Arcadeshopper does have 64K boards if folks are interested in those. :-)

Edited by acadiel
  • Like 1
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...