Jump to content
IGNORED

4K Basic Support Module


acadiel

Recommended Posts

Rich Gilbertson and I had a great conversation last night around the BASIC Support module.  According to Ksarul "The BASIC Support Module was a development cartridge with some additional routines in it that gave the developer a version ofBASIC that was more functional than TI BASIC, but nowhere near as capable as Extended BASIC."

 

There were two versions of it.  Yep, two.  A 4K and a larger one.  Rich helped with that discovery after reading the code and looking at the 4K EPROM of the one we had.  Physical copies exist of the 4K one - Ksarul has two of them.  Bob Childress has another.  (I plan on trying to bid on it when he puts it up so I can help preserve it and to get it working in the UberGROM.)

 

Rich and I are working on getting the 4K version working in the UberGROM, using the ability of the UberGROM to have an 8K GRAM bank.

 

I've attached pictures of the 4K version. 

  • There is a 4K EPROM (mfgr varies) which has a little less than 2K of code with CALL @XXXX type calls.  They all begin with @. 
    • BASICSUP is the ROM.  Note that it's 6K in my image, but should really be 4K.  Most everything after 2K is blank.
  • There is also a 2K SRAM inside (mfgr varies.)  These can be easily breadboarded and replicated. 
  • It's all discrete logic that emulates GROM/GRAM.
  • The cartridge comes up with three menu options when you boot it:
    • 2 For GPL Prog at G(>7000)
    • 3 For CPU Prog at G(>7000)
    • 4 For CPU Prog at C(>6000)
  • Note that there is no Cart space RAM (C>6000) in here, but it appears to support it.
  • Some calls work, some don't.  According to Rich, the GPL in the EPROM is broken.  He is working on getting it fixed.
  • It's important that either myself or someone else gets Bob Childress' copy in the eBay auction and dumps it so we can compare it to Ksarul's.  I will be bidding on it and trying to buy it so I can analyze it and preserve it.  I'm afraid of cart collectors trying to bid the price up on it.  Bob doesn't have the capability to dump the 4K EPROM inside, unfortunately, before he sells it, and I doubt he would want to mail it to someone temporarily before he sells it - he sounds like he just wants to sell it and be done with it.

 

There is a larger version, too, and that one is the attached one below that Ksarul re-typed the source code for.  This version, according to Rich, has XB related calls in it and was made to work in that environment.  It's different from the 4K BSM in that there's a lot of Editor Assembler in it, and XB calls.  Was this ever produced?  We don't know.  The first part of Jim's document about the CALLs and such is relevant to the 4K version of the BSM, but the source code is not.  The source code is way more expanded, so TI must have had a larger version of the BSM planned at one point.  

 

Anyway, I'm putting this thread here so that everything is in one place.  Thanks to Rich for helping make the discovery about the two versions, Jim for scanning in the docs and providing the 4K ROM to analyze, and Bob for putting up internal pictures so we could compare the two.

 

Manual:  

 

 

bob1.jpg

bob2.jpg

bob3.jpg

bob4.jpg

bsm-ksarul1.jpg

bsm-ksarul2.jpg

91272928_229449954840224_1861610087907328000_n.jpg

Edited by acadiel
  • Like 9
  • Thanks 2
Link to comment
Share on other sites

1. Using FORTH GPL Disassembler as that was always my best one.

2. Fix the resulting code as it comes out backwards on many commands.

3. Compile and test the code.

4. Fix errors and fix so it works in Classic99 instead of some strange set up on hardware.

  • Like 2
Link to comment
Share on other sites

As I learned some years ago when Mark Wills and I were tracking down bugs in his excellent TURBOFORTH package, fixing a program to run in Classic99 is no guarantee that it will work in ANY TI real gear configuration. MAME (MESS) is a far more accurate representation of TI hardware but Classic99 is much easier to configure and use.

 

Mark used Classic99 for his development work and since he didn't have a working TI system at the time, used MAME (MESS) to test along with having me test TURBOFORTH on my real-gear system.

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

42 minutes ago, atrax27407 said:

As I learned some years ago when Mark Wills and I were tracking down bugs in his excellent TURBOFORTH package, fixing a program to run in Classic99 is no guarantee that it will work in ANY TI real gear configuration. MAME (MESS) is a far more accurate representation of TI hardware but Classic99 is much easier to configure and use.

 

Mark used Classic99 for his development work and since he didn't have a working TI system at the time, used MAME (MESS) to test along with having me test TURBOFORTH on my real-gear system.

I've volunteered to be the guinea pig for Rich to do the testing on real iron.

 

If you think about it, Once the code is fixed, we can have a powerup routine in another GROM Bank (4, 5, 6, or 7) relocate the 4K code to a GRAM bank (G3).  Then branch to the selection screen.  So, G3 will then have a copy of the code, but since it's gram, the 2K it thinks it has (or actually, upper 4K since we use 8K GRAM not 6K) is writeable, just like the original module.

 

  • Like 1
Link to comment
Share on other sites

2 hours ago, RXB said:

There was a program disk called DISASSMBLER written in FORTH for GPL DISASSEMBLY

does anyone have a copy, I can not find mine anywhere?

 

Do you know what Forth it was written for? I am guessing TI Forth, but Wycove Forth was out there as well. And, possibly, others.

 

...lee

  • Like 1
Link to comment
Share on other sites

Ok I have from Jon a dump of BSM but how do I get the DUMP into Classic99 to use my GPL DISASSEMBER as unless it is in memory it can not look at a file on disk?

 

 

Can you move a DUMP into GROM 3?

 

Is there some way to do that?

Link to comment
Share on other sites

4 hours ago, RXB said:

Ok I have from Jon a dump of BSM but how do I get the DUMP into Classic99 to use my GPL DISASSEMBER as unless it is in memory it can not look at a file on disk?

Can you move a DUMP into GROM 3?

 

Yes. See Classic99 Manual, page 33.

 

...lee

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

I think he's asking the other way - from disk into Classic99?

 

To do that, just make a cartridge using Classic99.ini, something like this:

 

[UserCart0]

Name="Test GROM"

ROM0=G|6000|1000|C:\myfiles\testdump.bin

 

Make sure Classic99 is CLOSED when editing Classic99.ini.

 

The ROM0 is the critical one:

"G" means GROM

"6000" means load at GROM address >6000

"1000" means load >1000 bytes (which is 4k, use "2000" for 8k)

And "C:\myfiles\testdump.bin" is the filename. Please put the file somewhere with no spaces in the path.

 

After you save and restart, it should show up in the Cartridge->User menu. If it doesn't show, check the debug log (do a File->Reset if needed to reload it) and make sure that it was able to find the file.

 

You probably need another cartridge to load your disassembler, in that case you can add another line (like ROM1 - the number is NOT the GROM number, it's just an unrelated index) to load that ROM. Obviously, if the addresses conflict then the last one loaded wins.

 

Or use MAME. I'm told it's far superior. ;)

 

  • Thanks 1
  • Haha 1
Link to comment
Share on other sites

5 hours ago, Tursi said:

I think he's asking the other way - from disk into Classic99?

 

To do that, just make a cartridge using Classic99.ini, something like this:

 

[UserCart0]

Name="Test GROM"

ROM0=G|6000|1000|C:\myfiles\testdump.bin

 

Make sure Classic99 is CLOSED when editing Classic99.ini.

 

The ROM0 is the critical one:

"G" means GROM

"6000" means load at GROM address >6000

"1000" means load >1000 bytes (which is 4k, use "2000" for 8k)

And "C:\myfiles\testdump.bin" is the filename. Please put the file somewhere with no spaces in the path.

 

After you save and restart, it should show up in the Cartridge->User menu. If it doesn't show, check the debug log (do a File->Reset if needed to reload it) and make sure that it was able to find the file.

 

You probably need another cartridge to load your disassembler, in that case you can add another line (like ROM1 - the number is NOT the GROM number, it's just an unrelated index) to load that ROM. Obviously, if the addresses conflict then the last one loaded wins.

 

Or use MAME. I'm told it's far superior. ;)

 

I can keep REA in GROM 7 as BSM does not have anything in GROM 5 or 6 or 7.

I use EA3 version of GPL DISASSEMBLER and have demoed it in many of my videos over the years.

Link to comment
Share on other sites

The only GPL Disassembler is on the second disk image and, even though the TI Forth boot program (FORTH) is on the disk, nothing else appears to be in Forth and FORTH hangs. It looks like it was designed to start in Extended Basic and both the GPL Disassembler and GPL Assembler start up OK.

 

The first and third disk images are the same TI-Forth-based TMS9900 Dissassembler on differently sized disks. Unfortunately, they do not work because the Forth blocks are misaligned. I am guessing someone attempted to copy the disks by copying files rather than sectors. This will essentially corrupt a TI Forth disk because the file SYS-SCRNS is set up on a TI Forth system disk to use all of the space not used by UNIVERSAL (renamed FORTH boot program) and FORTHSAVE (program image loaded by UNIVERSAL) and to make it appear to any catalog program as a full disk. The blocks are actually written in four-sector chunks to the disk by TI Forth without regard to the layout of file SYS-SCRNS. In fact, there is nothing preventing overwriting the startup program and program image!

 

I will work on trying to re-register and sort the blocks into a working system, but, if there is any actual corruption of the blocks, I won’t stand a chance of success. We shall see.

 

...lee

  • Thanks 1
Link to comment
Share on other sites

  • 2 weeks later...
1. Using FORTH GPL Disassembler as that was always my best one.
2. Fix the resulting code as it comes out backwards on many commands.
3. Compile and test the code.
4. Fix errors and fix so it works in Classic99 instead of some strange set up on hardware.
I've posted it on eBay

Sent from my SM-G988U1 using Tapatalk

Link to comment
Share on other sites

30 minutes ago, Nervebreaker said:

I've posted it on eBay

Sent from my SM-G988U1 using Tapatalk
 

Working on finishing RXB 2020 and will go to work full time on BSM project.

Right now just finished full USER demo that creates programs on DISK 1, 114 Sector DV 80 file creates 159 sectors of XB programs and files.

So my CALL USER using DV80 files works much like a compressed file creator.

The blow away will be RXB 2020 SAMS support changes.

  • Like 6
Link to comment
Share on other sites

12 minutes ago, INVISIBLE said:

Would you be open to accepting a suggestion for the inclusion of one small, but useful addition that would be of benefit to a substantial portion of the current TI population here at AtariAge?  

This likely is going to be a two phase project.

 

First, Rich and I have spoken about preserving the cartridge pretty much as-is on the UberGROM.  We have to make some changes to get it to work.

  • We will map G4 in the UberGROM as GROM.
    • We will move the lower 4K of the GROM G3 (from the original BSM cart) to the UberGROM's G4 GROM bank.
  • We will map G3 in the UberGROM as 8K of GRAM.
    • A powerup routine in G4 will copy/unroll the 4K GROM of the BSM from G4 into the lower 4K of G3 (which is GRAM)
  • The powerup routine will branch to the selection screen so you can see the three menu items (or BASIC)
  • When you get into BASIC, you should be able to use the "GRAM" on the cartridge, which is (now) the upper 4K of G3 (GRAM).  You could also potentially wipe out the lower 4K of G3 where the BSM stuff is (because this is GRAM as well.) 

The above should make the module work as originally intended.

 

Secondly, Rich has some great plans for enhancing the module way beyond the capabilities it originally had.  I'll let him detail those plans, but from what he told me over the phone, it sounded freaking awesome.

 

  • Like 2
Link to comment
Share on other sites

45 minutes ago, Pheonix said:

Asked in another thread & pointed here:

 

What is the limit (amount & location,) of RAM (GRAM, VRAM etc...) that can be placed in a cartridge?  I've often wondered....

Depends on how much you want to support.  This is a ROM and RAM discussion.  (This is based upon my understanding, and some may be incorrect, which I'll lean on the titans to help correct me if needed.)

 

TI made eight GROM addresses available.  GROMs 0-2 are the console, and 3-7 are available in the module.  From the TI Tech Guide:

GROM 0: >0000-17FF - console boot/OS
GROM 1: >2000-37FF - console TI Basic
GROM 2: >4000-57FF - console TI Basic
GROM 3: >6000-77FF - cart
GROM 4: >8000-97FF - cart
GROM 5: >A000-B7FF - cart
GROM 6: >C000-D7FF - cart
GROM 7: >E000-F7FF - cart

For the five GROMS in a cartridge, you can have up to 30K (if you use 6K GROMs) or 40K (if you use 8K GROMs.)

 

There are also 16 "sets" of the cartridge GROMs that can be used (i.e. "REVIEW MODULE LIBRARY").  16 that are decoded, 256 I think are technically capable.  >9800, >9804, >9808, etc.  up to technically >9C00.  

 

So, to me that means 6K * 5 * 16 = 480K of GROM in 6K increments, or 8K * 5 * 16 = 640K for all sixteen banks the stock console will recognize via Review Module Library.  Or, for the max of 256 - 6K * 5 * 256 = 7680K for 6K GROMs or 10240K (1M!) if using 8K GROMs.  Anything past 16 needs custom code.  These bases could also very well be GRAM.

 

So, that's GROM.   ROM/RAM is a bit different.  There's only an 8K window available for ROM/RAM.  Common carts ROMs can go from 8K all the way to 2M using bank switching circuitry (we used all the data lines).  Tursi's Dragon's Lair even went further by using address lines as well as the data lines - he pushed it to probably its very limits.  We implement our bank switching for ROMs by writing to certain RAM addresses (which wouldn't work with RAM - we'd overwrite stuff).

 

For RAM, we've built supercarts that allow for 8K or 32K in the 8K cartridge ROM space of >6000.  The non CRU based supercarts use switches to manually switch between four 8K banks.  The CRU based one (SuperSpace) probably can only go to 64K (maybe 128K) with the technique it uses for CRU bank switching.  

 

Then, you have the UberGROM.  If you use the basic GROM/GRAM functionality, you can map any of the five banks as GROM or GRAM.  You can have up to 40K (5 banks) of GROM and 2 banks of GRAM (8K/7K).  There's also some small flash EEPROM space and other functions (Serial, Timer, ADC, etc.)  I'll let Tursi chime in if he wants to explain the additional GROM bases and limits there, because the ATMega 1284P only has so much space on it.  

 

Does this help?

 

 

 

 

 

  • Like 2
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...