Jump to content
Tursi

F18A ROM-based Updater

Recommended Posts

Classic99 was not only unused, it was outright rejected when I first released it.

 

Damn, I cannot fathom my TI hobby without Classic 99! Not only is that program responsible for sucking me back into the hobby, it's a great pairing with "Real Iron", especially with the HDX.

 

 

... my next project is too large for even the FlashGROM99. So guys, don't solder down your cart ports yet. icon_wink.gif

 

Oh dude, you really know how to bait a guy. icon_biggrinwink.gif

 

 

As for Wolf3D... the F18A GPU has more than enough horsepower to pull off a decent raycaster. icon_wink.gif

 

We'll see what the future has in store!

Share this post


Link to post
Share on other sites

As for Wolf3D... the F18A GPU has more than enough horsepower to pull off a decent raycaster. ;)

 

The problem, again, is the RAM. Say we want raycasting on half of the screen, that's 6K of bitmap layer. But we probably need to double buffer it, so that's 12K. Then we need a GM1 layer for the other parts of the screen and some pattern for that, so that's perhaps another 2K. Then we need to store some soft sprites and textures, that's at least another 2K. Then we only have 2K left for the raycaster and the world map.

 

It's tight, but doable. If we could manage without the double buffering that would help a lot, of course.

 

 

Keep in mind there is about 640K worth of Flash memory available to the GPU. The core game could be in the dedicated 2K of GPU RAM, with a 2K block of VRAM dedicated for swapping code in from Flash as needed. It would not be too much different than dealing with a cartridge. The Flash is clocked at 160ns/byte (100K per frame (16.6ms), or 6.2MiB/sec, or 330us for 2K (about 5 scanlines)). The host computer could also be coaxed into being a storage unit for the GPU, along with the I/O.

 

If there any way the flash could be used for double buffering?

Share this post


Link to post
Share on other sites

I find it difficult to come up with ideas for programs that require all that memory, and couldn't be done with a ROM cart instead. Do you have some good ideas?

 

My first thought was a spell checker feature for a word processor. The wordlist file on a Mac, /usr/share/dict/words, appears to be about 2.5 MB in size (uncompressed). However, as I think about it, the main part of a word list is unchanging, so this could probably be put in a bank-switched ROM.

 

My next thought would be a text file viewing application like the old MS-DOS list.com program. The text viewer could load large ASCII files into memory and allow the user to search for strings and randomly page up/down through the file at blazing speed. To do this with only 32 KB of RAM, for large files, would require paging/chunking the file from disk. For just viewing, that might not be so bad, but for searching, it could cause a lot of disk thrashing. If the whole file were loaded into memory, it's much easier.

Share this post


Link to post
Share on other sites

Not really, the flash would be best used as a read-only resource store for code, graphics, sounds, etc.

 

Actually I think it might possible to draw the whole screen for a raycaster during vertical refresh, so no double buffering would be needed. Then we could expand the bitmap to 2/3 of the screen and still have 4K more available. The question is whether we would get the best results using a 4 color bitmap or a 16 color fat-pixel bitmap?

  • Like 1

Share this post


Link to post
Share on other sites

I'm not the most knowledgeable guy around here when it comes to memory locations or assembly language programming, but I wonder, are some commonly used programming conventions 'locked in stone'?

 

It's common to see games in multiple pieces, like War Zone II was before one of our resident programming wizards stuffed it all into a single .BIN. But that was 'just' a standard E/A 5 game. What about a multi-bank UberGROM mega-sized program... AND STILL have the levels load from disk for an even larger and more spectacular mind blowing program? Who says things have to be in one piece?

 

If taken to 'the next level' I can imagine a huge program stuffed into the entire contents on an UberGROM, but also requiring the full capacity of the 1meg SAMS card and the enhanced capabilities of the F18A. Like somebody else said, why build the hardware if no one is ever going to use it. Many of us ALREADY have the required equipment, and those who don't will be given a pretty compelling reason to upgrade! icon_evil.gif

 

The disk based Monopoly game uses a SAMS loader, who say's a cartridge cannot do the same for loading levels into a SAMS card before game play begins?

  • Like 1

Share this post


Link to post
Share on other sites

Not to say you're wrong, but it's worth noting that a 512k has more space on it than any removable disk system currently available for the TI, unless you count using an entire CF card. ;) 180k is the largest reasonable maximum, since nearly everyone has at least DSSD. That's why you wouldn't be too likely to see a 512k cartridge that also loads from disk - the complexity of adding loading from disk to get just 30% more data, at a very slow comparable rate, wouldn't be worth it to me. If you went UberGROM cart you get 120k of GROM space which is almost as much space as the floppy offers, and it's almost as fast as the ROM for loading (at least when compared to a floppy disk).

 

As for filling the 1MB SAMS - again, where's it going to come from? Unless you are generating data or using a large map, I've done the math for that one already. ;) If you're loading from 180k floppies you're going to be sitting there for a while as you swap six floppy disks to get the game started. ;)

 

And 512k isn't the maximum cartridge size. We already have a 2MB cartridge laid out and in production, available today. Now you've doubled the AMS RAM size, you have plenty of room. If you were ambitious, your cartridge can hit 32MB without changing the bank switch concept - just keep adding latch bits.

 

In short... loading from disk doesn't give you anything you can't already get from cartridge. And the cartridge is self-contained, the user doesn't need to have additional pieces. The AMS can still be useful - RAM is always nice to have handy, but I don't see the value of a large cartridge combined with disk loading. ;)

  • Like 2

Share this post


Link to post
Share on other sites

Yeah, now that I think more about it, you make perfect sense... but honestly, once the FG99 is released, as proof of concept, I want to see Monopoly put on it.

Share this post


Link to post
Share on other sites

Hi, you know that I am clueless to this things, but,

isn´t it possible to burn ie the Monopoly.bin as usual into the UberGROM (or any other),

and also burn the needed Disks for that into it too, into an "Extra Free Space" EFS :) ?

 

So an "emulated & deviated DSR" to access this virtual (Read-Only)-Floppies (DSK#1 -> DSK#x) in the chip would be needed, of course...

Maybe something like the NanoPEB does this ?

Yes I know, the Nano sits on the Sideport (DSRs), but using an "emulation" for that DSK-Address/Access through the cartridge port,

maybe someone can "bend" that, as it is just "software" ?

Share this post


Link to post
Share on other sites

Yeah, now that I think more about it, you make perfect sense... but honestly, once the FG99 is released, as proof of concept, I want to see Monopoly put on it.

 

You could just make a FR99 image with ABOOT and keep all the other files on DSK1. :)

  • Like 1

Share this post


Link to post
Share on other sites

 

You could just make a FR99 image with ABOOT and keep all the other files on DSK1. icon_smile.gif

 

Yes, I suppose one could, especially since anyone with a SAMS probably has a disk drive anyway.

I suppose the REAL CHALLENGE would be if some wizard could get the whole thing to work within the confines of the FG99 without the need of a SAMS card. Nawwww.

Share this post


Link to post
Share on other sites

 

Yes, I suppose one could, especially since anyone with a SAMS probably has a disk drive anyway.

I suppose the REAL CHALLENGE would be if some wizard could get the whole thing to work within the confines of the FG99 without the need of a SAMS card. Nawwww.

 

Of all the disk programs that could be converted to FG99, TI-Nopoly is probably one of the most difficult. AFAIK it is an example of overlay programming that's tied closely to the SAMS and the AEMS system, and is using bank switching that's much more advanced than what you can do with a ROM cartridge. Perhaps it could be hacked to load from cart instead of disk, but it would still require SAMS.

Overlay programming.txt

  • Like 2

Share this post


Link to post
Share on other sites

Quick question before I go out the door this morning.  Is the F18A still at 1.8?  If not, a new FG99 loader might be useful for the masses, myself included.

Share this post


Link to post
Share on other sites

V1.9 is the latest and fixes a timing bug that has been in the design since its inception.  See the first post the F18A Resources thread:

 

https://atariage.com/forums/topic/207586-f18a-programming-info-and-resources/

 

There is an in-system updater for the 99/4A and ColecoVision.  If the FG99 can help with that in some way, I don't know (don't have one, never used it, not paying very good attention these days).

Share this post


Link to post
Share on other sites
V1.9 is the latest and fixes a timing bug that has been in the design since its inception.  See the first post the F18A Resources thread:
 
https://atariage.com/forums/topic/207586-f18a-programming-info-and-resources/
 
There is an in-system updater for the 99/4A and ColecoVision.  If the FG99 can help with that in some way, I don't know (don't have one, never used it, not paying very good attention these days).
The updater works great from TIPI

Sent from my LM-G820 using Tapatalk

Share this post


Link to post
Share on other sites

Tursi put together the 1.8 image that works in UberGROM's and in the FinalGROM.  Many people used that image to upgrade due to hardware issues.  If a new 1.9 was cobbled together I expect it would be well received, not to mention well used.

Share this post


Link to post
Share on other sites
On 12/17/2019 at 11:49 AM, --- Ω --- said:

Tursi put together the 1.8 image that works in UberGROM's and in the FinalGROM.  Many people used that image to upgrade due to hardware issues.  If a new 1.9 was cobbled together I expect it would be well received, not to mention well used.

It's there at the link Matt posted, he updated all the tools for 1.9 (or I did, or someone did. ;) )

 

(The zip file contains both a 256k and 512k update ROM, a 400k CF7-sized DSK image, a 256k ColecoVision ROM and the raw bitstream files.)

 

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