Jump to content
Tempest

TI99 Infocom Games

Recommended Posts

You know, I am kinda surprised nobody has attempted to make a new generation geneve.

 

There are at least 3 projects I know of that attempt to recreate a TI 99/4A, either with discrete parts or with an FPGA..  Yet no Geneve clones?  I find that odd.

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, wierd_w said:

You know, I am kinda surprised nobody has attempted to make a new generation geneve.

 

There are at least 3 projects I know of that attempt to recreate a TI 99/4A, either with discrete parts or with an FPGA..  Yet no Geneve clones?  I find that odd.

FarmerPotato is in the process of creating the Geneve 2020.

  • Like 1

Share this post


Link to post
Share on other sites
5 hours ago, arcadeshopper said:

yes it can be a supercart.. reasonably sure there's a supercart image in the finalgrom cart file on whtech if not it's documented in the github page

Thanks! I'll take a look.

  • Like 1

Share this post


Link to post
Share on other sites

I guess I don't know what I'm looking for in the FG.  I've got the latest image loaded from whtech.  I've looked through the dev folder and I don't see a Supercart choice on either page. Ditto in the tools folder. What should I be looking for?

  • Like 1

Share this post


Link to post
Share on other sites

From the FinalGrom99 website:

 

Quote

Advanced Modes

Most legacy cartridge images and homebrew programs will run as-is on the FinalGROM 99. This includes games, educational programs, tools, and programming languages.

But the FinalGROM 99 also offers two advanced modes that emulate advanced cartridge types that did not exist previously:

  • [R] RAM Mode: provides up to 512 KB of ROM and 512 KB of RAM
  • [G] GRAM Mode: turns occupied GROM into writable GRAM
  • [X] RAM/GRAM Mode: provides both RAM and GRAM

To enable one of these modes for a specific image, put character R, G or X at image offset 3, also known as "reserved" byte. For legacy images, you may use a Hex Editor to modify the fourth byte. For new images, your GPL header would start like

aorg >6000
data >aa01
byte >00, 'R'  ; activate RAM mode

Note that each image type can use only certain modes, e.g., a ROM-only mode cannot use GRAM mode.

These advanced modes are mostly targeted at developers (see "How to Develop"), but RAM Mode is also required for running the Mini Memory image.

 

So, since there isn't an option to specify the RAM size (always fixed at 512kb!), just load mini memory cart image.

Share this post


Link to post
Share on other sites

Nevermind, I am a tool.

 

The minimemory only does 4k, and does not bank switch. The page I quoted from has some caveats that says that the RAM that gets emulated needs to be preloaded to be available, meaning it has to be in the image file. The minimem does not have this second requirement, so wont work.

 

I am not finding a suitable dump for the supercarts. 

 

Does anyone have one?

  • Like 1

Share this post


Link to post
Share on other sites

Thanks! Unfortunately, when the program runs from minimem or minimem+ it is just gibberish flowing on the screen.  Believe it or not that is progress.  If I run from XB (there is a LOAD file in the disk image), the program starts but says a Supercart is required and to start from E/A option 5 with filename DSK1.LEATHGODDS.  There is no option 5 in minimem, so I used load and run.  I also tried run.

 

Sorry Weird, i didn't see your second reply before posting.  That explains my result.  Thanks for your efforts!

Edited by DuaneAL
Acknow;edged second reply

Share this post


Link to post
Share on other sites

The supercarts are an E/A cart, with an 8k ram bank tacked on.

 

It might be possible to manually doctor an E/A cart image so that it makes the FG99 act like a supercart when loaded.

 

See this quoted section

 

Quote

Filenames

Images are single files or multiple files with a common root name. All filenames must end in .bin, and case is ignored. Files with other extensions are ignored.

A GROM-only image is always a single file whose filename ends in G:

hellog.bin

IMPORTANT! The trailing G indicates that the file contents are GROM code, so ROM files must not end in G!

A mixed ROM and GROM image is always split into up to 3 files, ending with C and D for the ROM files and G for the GROM file:

helloc.bin
hellod.bin   (optional)
hellog.bin

For mixed images, the ROM file must always end in C, but an optional second ROM bank ending in D may be present. The GROM G file may be up to 40 KB in size, whereas the ROM C file may be up to 960 KB in size. If a D file is given, it must be exactly 8 KB in size.

Finally, ROM-only images may be a single file of almost arbitrary name or split files like in the mixed case. When using a single file, the filename must not end in D or G.

The split file format has been used for virtually all cartridge dumps for several decades now.

The filesystem used on SD cards has an filename character limitation, which ignores case and shortens all filenames to fit into a 8.3 schema. Thus, hellogromg.bin would be seen as HELLOG~1.BIN, and the trailing GROM indicator G would be missed.

IMPORTANT! When using split files, make sure that each filename has no more than 8 characters (excluding the extension)! This is always true for legacy cartridge dumps.

HINT: A filename with more than 8 characters for a single file ROM-only image will never end incorrectly in D or G.

In summary, don't rename cartridge dumps. GROM filenames must not exceed 8 characters AND must end in G. ROM filename must have more than 8 characters OR must not end in D or G.

For all images, there is always a main file that is used for help texts or RAM/GRAM configurations. For GROM and mixed images, the main file is the G file, for ROM-only files this is the C file or the actual filename of a single-file image.

 

So, if I am reading this correctly, if you took the E/A cart rom set, doctored the magic byte so that it contains "R", and then tacked on a second filename ending in D.bin of the size of RAM you wanted, it theoretically would function as the supercart...

 

I think.

 

 

Share this post


Link to post
Share on other sites
2 hours ago, wierd_w said:

The minimemory only does 4k, and does not bank switch.

Here I made this and have used it a lot in the past. My FG99 is using a doctored banking sys. So I used the newest GROM file. Mine would not work for others.

 

I didn't test this right now... but it should work!

 

Switch RAM banks by writing upward by 2 from >6000.

 

>6000 = page 1

>6002 = page 2

>6004 = page 3

 

512k less several banks, takes around 10 seconds to load each time. GROM banks use-up some of that 512k space.

 

                   256k Banked Minimem.zip

  • Like 2

Share this post


Link to post
Share on other sites
1 hour ago, HOME AUTOMATION said:

Here I made this and have used it a lot in the past. My FG99 is using a doctored banking sys. So I used the newest GROM file. Mine would not work for others.

 

I didn't test this right now... but it should work!

 

Switch RAM banks by writing upward by 2 from >6000.

 

>6000 = page 1

>6002 = page 2

>6004 = page 3

 

512k less several banks, takes around 10 seconds to load each time. GROM banks use-up some of that 512k space.

Oops, I forgot to add the Minimem ROM data to page 1!

I Can't seem to remove attachments anymore... sigh.

 

 

 

Fixed...

 

                           256k Banked Minimem.zip

  • Like 1

Share this post


Link to post
Share on other sites

There isn't any reference in his FinalGrom docs on how to enable 8K RAM in the 6000-7FFF area.  Looks like we need to ask him to add SuperCart support.  Maybe use a upper case "R" for SuperCart (8K RAM) and a lower case "r" for MiniMemory (4K/4K ROM/RAM split).

Edited by Torrax
  • Thanks 1

Share this post


Link to post
Share on other sites

As HomeAutomation points out, you need a way to switch banks. The whole cartridge width is 8k.

 

To bank on a hybrid cart (ROM + RAM) you do a latch on write to the ROM area. This tells your latch what part of your SRAM to expose on the window.

 

This is the banking scheme used by the FG. 

Share this post


Link to post
Share on other sites
11 hours ago, HOME AUTOMATION said:

Oops, I forgot to add the Minimem ROM data to page 1!

I Can't seem to remove attachments anymore... sigh.

 

 

 

Fixed...

 

                            256k Banked Minimem.zip 264.29 kB · 5 downloads

 

now if the actual minimem's DSR was updated to support the banking, that would be a real treat. (256kb ramdisk, without touching the 32k area!)

 

  • Like 1

Share this post


Link to post
Share on other sites

Unfortunately, I have never used a TI RAMDISK.

I imagine their main/sole purpose is to speed-up file processing? That hasn't been a big issue for me.

Share this post


Link to post
Share on other sites

It could be a useful area to store volatile data;

 

Say for instance, you have a program that sends some kind of datagram to a TIPI regularly, that is generated by some small bit of program code, but you dont want to always be executing the code that generates it, because of the limited stack space available.  Instead, you generate out the whole stream, then reduce your sending code to "read X byte sequence from volatile file X, send to tipi TCP Raw handler"  etc.

 

It would be useful for midi music scores (which could be packed with a compression algo pretty nicely, but you dont want to lug that in your main process) and the like.

Share this post


Link to post
Share on other sites

I dunno, It's the same memory either way. DSR's and file processing seem like they would only add overhead, with good memory management techniques, direct access should tend to allow better streamlining of data flow.

 

It looks to me like DSR's are mostly for seamlessness/compatibility.

 

The DSR(s) in MINI MEMORY:

 

"MIMIMEM"
"EXPMEM1"
"EXPMEM2"

 

Can hold only a single file at a time.

 

However by switching the RAM pages... you can store many separate files!

 

I explained it wrongly in post #85.(haven't used it for some time!)

:roll:

 

CORRECTION:

 

ROM pages are switched by writing to:

 

 6000=page 1
 6002=page 2
 6004=page 3

 

RAM pages are switched by writing to:

 

 6800=page 1
 6802=page 2
 6804=page 3

 

Page switching can be done from EASY BUG or by way of CALL LINK
combined with a small assembly routine, either copied to all pages
or stored in a nonpaged RAM address range.
 

Share this post


Link to post
Share on other sites
On 11/9/2019 at 8:56 AM, wierd_w said:

I am not finding a suitable dump for the supercarts. 

 

Does anyone have one?

I did hunt WHTech, many DSKs for SUPERCART/SCART here:

 

ti-filename_pc-filen..>

 

a couple here:

 

ti99sim/

 

But they wont help.

 

I ran leather goddesses from Classic99 (Funny game disclaimer! HA!). I checked the debug log, and disassembled a little, it uses >2000->3FFF and >6000->7FFF and runs sections of code from >8300. Looks to me like this would be difficult to relocate. Many absolute address refs. in all sections. It looks like Classic99 uses SAMS memory to run it though!

 

I think FG99's designer, might be able to accommodate this mode, if FG99 has access to the CRU lines. I Dunno!

 

 P.S. Does any one know why I can't do spoilers anymore!;)

Share this post


Link to post
Share on other sites

MINIMEM is the file system of the 4k on-board memory.  EXPMEM1 and EXPMEM2 are the 8k and 24k memory banks, respectively, in the 32k memory expansion.  Beware, however, as the MiniMemory DSRs contain a couple of bugs, detailed at the TI Tech Pages.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

True, but I can't think of a single time it's come up.

By following your own set of procedures, rather than TI's, all should become copacetic.:thumbsup:

 

Since the MINI MEMORY has several idiosyncrasies, and I LOVE IT, especially when PAGED.

I think I'll begin a new TOPIC on this and PAGING in general!:party:

Share this post


Link to post
Share on other sites

OK, another use case for a virtual minimem+page (with better DSR) on a finalgrom:

The most recent FG firmware supports saving the minimem memory to the SDCard. (Important!)

 

 

Base system with no PEB or PEB-alike; User would REALLY like to use some disk based games, but simply cannot get one (PEB like solution). (These things occasionally become available, but waiting can be a long time. FG99s appear more regularly on places like Ebay.)

 

Since this would require a rewrite of the DSR in the first place, (and the FG allows paging of the ROM area as well), a fully proper ramdisk that gives a DSK1 device, coupled with the "save minimem memory" support, == FG99 "now a 'disk based' game storage option"

 

 

If you combine that with some way to get programs files off cassette reads (eg, binary ones, not just basic files) and save them to arbitrary file names, a slow but laborious process to load the "enhanced minimem" with disk based games becomes possible. (of course, they could just inject the necessary data into the FG99 rom image instead. :))

 

 

Edited by wierd_w
  • Like 1

Share this post


Link to post
Share on other sites

Not so surprisingly, I have been considering exactly this, but it's not on my to do list yet...

 

SAVE or LOAD type FILE operations using less than 4k would be simplest, but OPENing and handling file types that use REC #s, especially the 8k DV, DF types common to TAGGED OBJECT CODE, would require a proprietary system.

 

I'm just not up to it now and  I don't really have need of it myself. But I would like to see it happen!:cool:

Share this post


Link to post
Share on other sites
On ‎11‎/‎10‎/‎2019 at 3:04 PM, HOME AUTOMATION said:

Unfortunately, I have never used a TI RAMDISK.

I imagine their main/sole purpose is to speed-up file processing?

That was the main issue for me. To be able to compile a quite comprehensive version of Pascal within the small memory of the TI 99/4A, the UCSD Pascal compiler is heavily segmented. This means the drives are spinning constantly during compile time, to reload different parts of the program during operation, in addition to reading the source code and writing the object code.

By placing the SYSTEM.COMPILER file on a RAMdisk, compile time is reduced to half, even if both the source and the object code files are on physical disks.

  • Thanks 1

Share this post


Link to post
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.

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