Jump to content

Photo

F18A ROM-based Updater


37 replies to this topic

#26 --- Ω --- OFFLINE  

--- Ω ---

    TI-Runner

  • 10,496 posts

Posted Thu Mar 30, 2017 4:41 PM

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!



#27 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,438 posts
  • Location:Denmark

Posted Thu Mar 30, 2017 11:07 PM

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?



#28 matthew180 OFFLINE  

matthew180

    River Patroller

  • 2,393 posts
  • Location:Castaic, California

Posted Thu Mar 30, 2017 11:44 PM

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



#29 BJGuillot OFFLINE  

BJGuillot

    Star Raider

  • 52 posts

Posted Fri Mar 31, 2017 6:16 AM

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.



#30 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,438 posts
  • Location:Denmark

Posted Fri Mar 31, 2017 9:05 AM

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?   



#31 matthew180 OFFLINE  

matthew180

    River Patroller

  • 2,393 posts
  • Location:Castaic, California

Posted Sun Apr 2, 2017 11:36 AM

IMO more color is always better.  But, four colors may be enough.  I would need to see both I suppose.



#32 --- Ω --- OFFLINE  

--- Ω ---

    TI-Runner

  • 10,496 posts

Posted Sun Apr 2, 2017 4:05 PM

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?



#33 Tursi OFFLINE  

Tursi

    River Patroller

  • Topic Starter
  • 4,784 posts
  • HarmlessLion
  • Location:BUR

Posted Sun Apr 2, 2017 4:59 PM

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



#34 --- Ω --- OFFLINE  

--- Ω ---

    TI-Runner

  • 10,496 posts

Posted Mon Apr 3, 2017 6:54 AM

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.



#35 schmitzi OFFLINE  

schmitzi

    River Patroller

  • 3,845 posts
  • ToXiC
  • Location:Germany

Posted Mon Apr 3, 2017 8:39 AM

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" ?



#36 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,438 posts
  • Location:Denmark

Posted Mon Apr 3, 2017 8:56 AM

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



#37 --- Ω --- OFFLINE  

--- Ω ---

    TI-Runner

  • 10,496 posts

Posted Mon Apr 3, 2017 9:29 AM

 

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.



#38 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,438 posts
  • Location:Denmark

Posted Mon Apr 3, 2017 12:37 PM

 

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.

Attached Files






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users