Jump to content
IGNORED

.BIN Repository - Images for cartridges that require "burning" - (NO LONGER UPDATED OR SUPPORTED)


Omega-TI

Recommended Posts

Not sure why I'm finding this difficult - I'm searching for cart images that will specifically work with a Green Cart (not 128k hacked). Is there a general image type I should be looking for (like all 32k images should work or something?). I just received 20 x 27512 eeproms and want to start playing around with cart images but don't know what I can use and what will not work at all with this cart. My first attempt, at some point this afternoon will be Turboforth. i understand i should fill the cart when dealing with smaller (8k) bins so there is no empty space. And I understand that it's the same bin. Like for Turboforth; Since it is only 8k, I should fill the eeprom space with that very same TF image. I may have asked this before but cannot locate the answer.

 

The TurboForth binary is 16 KiB, not 8 KiB. You will need to copy it 4 times to fill a 27512.

 

[Edit] Also, binaries for the green boards must have their banks in inverted order. If they are in normal (non-inverted) order, you will need to re-order them before burning the 27512.

 

fbForth 2.0 is 32 KiB, so you would need two copies in the 27512.

 

Both TurboForth and fbForth 2.0 binaries are supplied in inverted order, so you will not need to re-order the banks. [/Edit]

 

...lee

Link to comment
Share on other sites

Most BIN files that were 64K and smaller were designed for the Inverted (Green or Black) boards. 128K files were for Black boards or hacked green boards. Anything larger than that was in the non-inverted format for the Red or Yellow boards. One note: the files (no matter what their size) in the FlashROM thread are non-inverted, IIRC, so not suitable without inverting them (Rasmus made a nice tool to do that)..

Link to comment
Share on other sites

Awesome Lee, thanks. What about other bins? If they are inverted and 512KiB or smaller, they will work with green board (using same copy rules for various sizes)?

 

Yes—as long as the programmer forces startup to the correct bank, which I know is the case with TurboForth and fbForth 2.0.

 

[Edit] The 27512 EPROMs are 64 KiB—not 512 KiB. They contain 512 Kib, i.e., 512 x 210 bits, which is the same as 64 KiB, i.e., 512 x 210 bits/(8 bits/byte) = 64 x 210 bytes. [/Edit]

 

...lee

  • Like 1
Link to comment
Share on other sites

One note: the files (no matter what their size) in the FlashROM thread are non-inverted, IIRC, so not suitable without inverting them (Rasmus made a nice tool to do that)..

 

And that tool is? :)

 

Not that I'd want to burn anything already suited for the FR99 but to add another tool to the toolbox in case of future need. I'm probably going to install a better socket for easily inserting and removing chips. Any recommendations on that - A ZIFF socket is what I've ready elsewhere.

 

EDIT: BTW - I've now made it a habit to "Print to PDF" all this info and saved logically on my PC for future reference. sometimes I lose these things and my search kung fu isn't that great. So thanks.

Edited by Sinphaltimus
Link to comment
Share on other sites

To further clarify my last post:

 

As long as the number of 8 KiB banks in the binary you want to burn to a 27512 EPROM evenly divides the number of banks ( 8 ) in the EPROM, you are safe just filling it with copies of the binary. This would be true for a binary of 1, 2, 4, 8 banks, i.e., 8, 16, 32 or 64 KiB. I am pretty sure there are no binaries produced for EPROM by this community that do not meet the above criteria. However, if there were, you would need to insure that the binary gets copied from the top down. Otherwise, the bank select codes would not work. I will explain this in greater detail later today unless someone beats me to it. Gotta run right now. TTFN

 

...lee

  • Like 1
Link to comment
Share on other sites

OK...Here is the promised bank-switching dissertation:


To switch to a particular bank in cartridge space (>6000 – >7FFF), you must perform a write operation to the selector address that corresponds to the desired bank. For banks in an 8-bank ROM selected by a normal-mode latch, start at >6000 and increment by 2 for each successive bank:


Selector

Bank Address

---- --------

0 >6000

1 >6002

2 >6004

3 >6006

4 >6008

5 >600A

6 >600C

7 >600E


In normal mode, bank 0 is always selected by writing to >6000.


When a latch is used in inverted mode, writing to >6000 selects the highest bank. For an 8-bank inverted ROM:


Selector

Bank Address

---- --------

0 >600E

1 >600C

2 >600A

3 >6008

4 >6006

5 >6004

6 >6002

7 >6000


Now, you see, bank 0's selector will be different for differently sized ROMs. For an inverted, 2-bank ROM like TurboForth, it will be:


Selector

Bank Address

---- --------

0 >6002

1 >6000


For an inverted, 4-bank ROM like fbForth 2.0, it will be:


Selector

Bank Address

---- --------

0 >6006

1 >6004

2 >6002

3 >6000


So, now you can see that for TurboForth to work in an 8-bank EPROM, you only need to put the working binary in the upper 16 KiB and insure that all of the other banks duplicate the startup code that switches to the startup bank. Of course, if you don't know which bank that is and which label is the entry point, it is enough to copy the binary to each 16 KiB section below the working binary. If, for example, the TI-99/4A starts up in bank 2, CLR @>6000 is executed, which switches to bank 7 (see 8-bank table) of the 27512 EPROM. This happens to be bank 1 of the 2-bank TurboForth binary, which now is situated in the highest bank (7) of our 27512 EPROM—and, off it goes. In fact, for both banks of TurboForth, the startup code switches unconditionally to bank 1 (bank 7 of our 8-bank EPROM).


Pretty much the same thing happens with fbForth 2.0 in that bank 1 is the initialization bank with every other bank switching to it with a CLR @>6004 (see 4-bank table). By inspecting the 8-bank table, you can easily see that writing to >6004 switches to bank 5 of the 27512 EPROM. Again, it is the upper 32 KiB of the 8-bank EPROM where all the action is.


I do hope this is a little clearer than mud. Let me know.


...lee

  • Like 2
Link to comment
Share on other sites

Lee - I understood everything you typed and the charts make it perfectly clear. I do not understand the actual process though in regards to LINKS. Are those LINKS already encoded in the data?
So essentially I just copy the data in to the eprom programmer software according to your chart layout for inverted banks switching?

So for a green board I can use 8, 16, 32 and 64k files. I start at bank 8 and count backwards until I have enough 8k banks to store the entire file, than I do the same in the empty space that's left to count backwards how many more banks I need for the data to fit and continue until all the space is full? So for 8k it would be 64 times on a 27512, 16k file would be 32 times for a 27512, ...then 8 times for a 64k file? 128k or higher not supported on the green board (128k only with hack).

Do I have that correct?

Link to comment
Share on other sites

Remember: the file is 8K Bytes, so that would be 64K bits in the ROM chip. The 512 in the chip is based in bits, so it holds 8 of the 8K Byte files (64K bits x 8=512K Bits). Use the answers I gave you for each chip type to figure out the right chip sizes for what you are trying to do. . . :) Have fun--a lot of folks get tangled in the interpretation of chip sizes at first, but once it sinks in, you'll be golden. :)

  • Like 1
Link to comment
Share on other sites

  • 1 month later...

There are probably some files I've overlooked including recently due to time and scheduling constraints. If you've posted any new .BIN's in the last 30 days or so, could you please post me a PM with a link to the message/thread. Once I get it, I can link it here so others in the future can more easily find and enjoy your work.

 

Thanks,

Ω

  • Like 1
Link to comment
Share on other sites

  • 3 months later...

 

Well, the intent is that you don't buy a blank AVR unless you know how to program it. The intent is you buy an UberGROM which has the firmware loaded on it and then you use GRMCFG to load the software right from your TI. Distributions for the UberGROM shouldn't really be including the AVR firmware, that's my software and isn't intended for distribution that way. My hope is they will just be GROM data, that's more useful to other systems as well, or at least backup images from GRMCFG if they use the other functionality.

 

EDIT: I guess what's really missing is full documentation on how to get from point A to B. Since life conspired against me offering B absolutely, we can put together a little guide. It looks like most programmers can handle the ATMega, so there's really only a couple of steps involved. At the simplest, though, if you are starting from a blank AVR, you can either program just the firmware, then mount it in the TI for the rest (that was the intent, it's the simplest and only needs to be done once), or you can program the firmware and the GROM data at the same time (quicker since there's no TI program stage, but a little more complicated and requires the data to be prepared for this approach). If the AVR isn't blank, you can do the same or just use GROMCFG on the TI side.

 

 

Document:

 

I totally forgot to upload this document (as I wanted to see how to burn "Buck Rogers" that time on the UberGrom) in August 2017

(Tursi gave me guidance in the High Score competition forum, but I still do not have enough knowledge to understand the banks,

invert, etc. (I still need to understand and learn GROMCFG, the problem is too busy with business and when I come back after travel,

I need to start all over again).

 

(reading Tursi thread above, I am not 100% sure if I now use AVR code (but I guess so when doing this procedure)

otherwise I could make the module, it seems these were posted in the forum before, the links of software are in the document?)

(Tursi let me know, I can send you the .doc format to change the procedure where needed and add GROMCFG info?)

 

 

UberCart-Programming-v1-Aug-2017.pdf

* Version 1.0 (with input from all - Tursi, Omega, the late Gazoo, Schmitzi, everone else I forgot).

 

* The procedure is focused on building the XB2.7 + SPEECH (when you insert the module it says "#Texas Instruments Home Computer#")

(info is a bit spread over multiple forum and images are located there)

 

* I did it step by step and this procedure works (let me know if you see something to be included / improved ?)

(also built the "Exbas Fun cartridge", the "8-1 Rasmus module" and an "Education module" that time),

but now with the FinalGROM module it is not needed anymore and now look for projects with require uberGROM

 

Other upcoming uberGrom project:

I still have 1x more project to do with UberGrom is with Fred Kaal's RS232 interface, but I have too much travel and business things

to do at the moment, hopefully X-mas give me some time to test it.

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

  • 1 month later...
  • 3 months later...

 

Tried these and they do not show up on my FlashROM 99. Could I possibly need some sort of firmware update?

 

Thanks,

Adam

 

You need a FinalGROM 99 for carts bigger than 32K + you need a 32K RAM expansion for these particular carts.

  • Like 1
Link to comment
Share on other sites

  • 1 month later...
  • 1 year later...
  • 8 months later...

Since the release of the FlashROM99 and the FinalGROM99, this section has become all but forgotten.  Still, if you use older cartridges using the inverted format, or want to make a specialty UberGROM burn, there are 'different versions' of some items.  However, as of today, I'm no longer actively supporting this thread.  If you want something posted, you'll have to send me a PM.

 

--- Ω ---

  • Like 1
Link to comment
Share on other sites

  • 7 months later...
Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

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