Using 8k - 512k MIMI MEMORY with PAGING on FinalGROM 99

[HOME AUTOMATION]

The image I've uploaded is preloaded in Assembly Language Storage mode(>7000=>A55A) with LINE BY LINE ASSEMBLER and the LINES demonstration program on PAGE 1(use NEW,OLD,LINES from MINI MEMORY option 2 RUN), (see MINI MEMORY pamphlet page 74).

 

Using SAVE MINIMEM from TI BASIC will force the current PAGE's (>7000 to >5AA5) TI BASIC Files mode(see MINI MEMORY pamphlet page 73).

 

Each RAM PAGE can have it's own mode.

 

Using the SAVE option after the TITLE SCREEN will save the current page to the SD card's image file.

 

I believe the main difference between the two modes is that in TI BASIC Files mode, you have no REF/DEF table. I tend to use absolute addresses anyway and keep tight control over all program/data sections/pages, loading from tape or by using EMU and a HEX EDITOR on the SD cards image file, rather than by using REFs and DEFs. But once again, each PAGE can have it's own mode.

 

One thing of note, might be, that when you LOAD, RELOCATABLE TAGGED OBJECT CODE from MINI MEMORY option 1, the loading destination is controlled by the following addresses:

 

>701C first free address in MEDIUM MEMORY (>7000-7FFF)
>701E last free address in MEDIUM MEMORY

 

>7022 first free address in HIGH MEMORY (>A000-FFE0)
>7024 last free address in HIGH MEMORY

 

>7026 first free address in LOW MEMORY (>2000,3FFF)
>7028 first free address in LOW MEMORY

 

The single REF/DEF table goes downward from >7FFF.

 

When the 32K memory pointers are not >0000, TAGGED OBJECT CODE will try to load in 32K, rather than MEDIUM MEMORY! So Best to ZERO these manually, So as to force code to load into MINI MEMORY.

 

From MINI MEMORY use option 3 RE-INITIALIZE  to clear/reset MEDIUM MEMORY before starting your project. Be aware that this will only RE-INITIALIZE the current PAGE!

 

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 an non-paged RAM address range.

 

So far I'm using this exclusively to run machine code, and to store data. Expecting the application(HOME AUTOMATION CONTROLLER) to grow as it is developed!

 

But I'm certain that there are other uses as well.

 

         Alex.

 

                               256k Banked Minimem.zip

Edited November 11, 2019 by HOME AUTOMATION

[Omega-TI]

Looks pretty cool.  I added it to the FG99 repository.

[+OLD CS1]

Will a CALL LOAD not also trigger the page change?

[HOME AUTOMATION]

Good thinking! Yes, a better way to do it.

 

Maybe I just like HEXADECIMAL too much.

ROM pages are also switched by writing to:

 

 24576=page 1
 24578=page 2.
 24580=page 3

RAM pages are also switched by writing to:

 

 26624=page 1
 26626=page 2
 26628=page 3

 

Example:

CALL LOAD(26626,0)
Switches to RAM PAGE 2.

[HOME AUTOMATION]

3 hours ago, --- Ω --- said:

Looks pretty cool.  I added it to the FG99 repository.

I made the cut. YES!

 

It's really just the original image, expanded with a HEX EDITOR.
Still, it has been truly handy for me.

 

It was a little tricky figuring out the largest size image possible. I'll upload that one later, but larger images take longer to load!

 

32k or 64k load pretty fast!

[HOME AUTOMATION]

This is the largest MINI MEMORY image I could create. 123 PAGES!

480k RAM = >7B000 = 503808 bytes.

 

 

                     480k Banked Minimem.zip

[wierd_w]

That's... Enormous.

 

 

Now I wonder if we could get adamantyr to rejigger his memory handling on his CRPG to work with this...  FG99s are a lot more plentiful than SAMS cards.

[HOME AUTOMATION]

I noticed there's a little discrepency in the naming conventions I used for the files...

 

256k Banked Minimem.zip (size includes ROM)

480k Banked Minimem.zip (size discludes ROM)

 

so...

 

256k image is actually... 32 PAGES

128k = >40000 = 131072 bytes RAM

480k image is actually... 123 PAGES

480k = >7B000 = 503808 bytes RAM

Maybe one of the files should be renamed.

Edited November 12, 2019 by HOME AUTOMATION

[HOME AUTOMATION]

22 minutes ago, wierd_w said:

That's... Enormous.

 

 

Now I wonder if we could get adamantyr to rejigger his memory handling on his CRPG to work with this...  FG99s are a lot more plentiful than SAMS cards.

I would like to see some other programming techniques for page management.

 

Sooo... I'll try to go first...

[HOME AUTOMATION]

First thing I wanted to do was, find a way to utilize all the RAM space for programming! After searching quite a bit and finding nothing, instead of asking, I took a stab at it myself.

 

I decided, since I already knew my program would use a lot of subroutines, perhaps occupying as much or more space as the main program, I would write the main program starting on the lowest page, growing upward, then write the subroutines starting from the highest page and growing downward.

 

Now I needed a way to switch pages from within the program, run the subroutine, pass data and then return.

 

I considered possibly using a couple STACKS, one to save return PAGE addresses and one to save return to "calling program" addresses. But for my first try I wanted to avoid using non-paged memory. I predicted that errors in the program's execution flow during development might be hidden in the stacks and not be as consistently detected. I don't like BUGS!

 

So I proceeded to try and create a page switching technique that uses helper code embedded on each page to store addresses juggled in WS REGISTERS during PAGE swaps.

 

This worked well for me at the time... thought it might help some others.
I hope it isn't "so dumb". 

 

       AORG >7140
       DEF  DS,OUTSAV
DS1    BYTE >7,3,2,6,7,8,9,6,>FF  * Data buffer example
MOVER  LI   R2,>A000     *********************************************
       JMP  MOVE         *    This section of code is moved to       *
NEXT   INC  R2           *    High Mem and than serves to pass       *
MOVE   MOVB *R0+,*R2     *    data between pages.                    *
                         *********************************************                                             
*      DEC  R1       why is this line here? I originally used a variable
*                    size buffer, w/o >FF (EOF byte).

       CB   *R2,@>A418
       JNE  NEXT
       LI   R0,>A000
       B    @>7136
FF     BYTE >FF
CLEN   EQU  $-MOVER      *********************************************
DS     LI   R0,MOVER     *                                           *
       LI   R1,CLEN      *   This section moves the above section    *
       LI   R2,>A400     *   up to High Mem.                         *
NOW    MOVB *R0+,*R2+    *                                           *
       DEC  R1           ********************************************* 
       JNE  NOW
       LWPI >AA00       this sets the WORKSPACE to High Mem

* your program goes here

* to call a subroutine on another page...

       LI   R0,DS1     Set R0 to buffer address of data to be passed
       LI   R8,>680C   Set R8 to subroutine's page
       LI   R9,>7D56   Set R9 to subroutine's address
       BL   @>A400     Call Mover to pass data and autocall suroutine

* your program continues here

_______________________________________________________________________

* this page switcher code goes at the top of all PROGRAM pages

       AORG >7130
CALLER CLR  *R8        Switch page
SAVRT1 B    @>0000     Saved return address of calling program
OUTSAV LI   R7,>680A   Set R7 to address of calling program's page(current page).
       MOV  R11,@>7134 Save return address of calling program to SAVRT1
       JMP  CALLER     Proceed to switch page
       END

* TO DO *
* A few more lines of code will go here, to allow PROGRAM pages to switch
* independently from subroutine pages. 
________________________________________________________________________

* this page switcher code goes at the top of all SUBROUTINE pages

       AORG >7130
DESTIN CLR  *R7    Switch page back
       MOV  R7,@SL Save return page of calling program
       BL   *R9    Execute subroutine
       MOV  @SL,R7 Restore return page of calling program
       JMP  DESTIN Proceed to switch page back
SL     DATA >0000
       END

______________________________________________

 Explaination of Mover:

       AORG >A400
MOVER  LI   R2,>A000   Load R2 with intermediate data buffer's address.
       JMP  MOVE       Proceed to load intermediate buffer
NEXT   INC  R2
MOVE   MOVB *R0+,*R2   Load first byte 
       CB   *R2,@>A418 Was it FF
       JNE  NEXT       If not proceed to move the next byte
       LI   R0,>A000   If so load R0 with pointer to data buffer
       B    @>7136     Proceed to program page switcher; OUTSAV
FF     BYTE >FF

 

Here is an example of this technique in action...

 

DTMF Encoder Demoed

 

DTMF Encoder Supplemental

 

The main program on the first page has the dialing # and branches to the dialing subroutine on the last page, the subroutine dials the # then returns to the main program, repeat, repeat, repeat, with no discernible delay between the first and the last dialed digits.

Edited November 12, 2019 by HOME AUTOMATION

[Omega-TI]

It's all above my pay grade, but I can see this being very useful to programmers and budding programmers.  Very impressive.

[HOME AUTOMATION]

Interesting enough, It's above my pay grade too! But this is what I do ...definitely still budding!

[+OLD CS1]

Remaking the game to support 4k paged MiniMemory versus 32k paged SAMS is probably a little more work than it is worth as it would require dividing up the program into 4k chunks (which takes planning) and relocating code to the >7000 space instead of the >2000 and >A000 spaces.  Not impossible and a challenge, but I suspect not practical for an established project.

[+FarmerPotato]

1 hour ago, OLD CS1 said:

Remaking the game to support 4k paged MiniMemory versus 32k paged SAMS is probably a little more work than it is worth as it would require dividing up the program into 4k chunks (which takes planning) and relocating code to the >7000 space instead of the >2000 and >A000 spaces.  Not impossible and a challenge, but I suspect not practical for an established project.

Also, this will not help with existing games  that load into 32k. It's simply not possible to rewrite those .

 

In case it wasn't stated clearly enough in this thread, no cartridge can map memory into the 32K space. The pins simply aren't connected to the cartridge port.

[+9640News]

Going to ask a question or three here since I saw the topic of inverted cartridges, etc. as I have been thinking about playing around with the FinalGrom99 cartridge ram features.

 

If on a Windows computer, I have a large file and I am using a hex editor, I would first setup the cartridge header.  Off the top of my head, I do not recall how many bytes that is.  I know it is at least 4, with thinking it may be 6 bytes???

 

If I then copy code, graphics, etc, over in 4K chunks, I could copy 4K x 128 chunts over from the end of the header to the end of the file.  Would this file then be useable "as is" or does it have to go through some kind of inversion procedure/script to be used by the FinalGrom99?

 

At this point, I am just trying to understand the basics.

 

As I was reading the notes on the FinalGrom99 yesterday, I noted modules could be chained and called up, so one could potentially string possibly up to the capacity of the SD card, any number of 512K images.  Does anyone have any experience on the delay between the execution of the call to change to a new image, or is pretty instantaneous?

 

Again, trying to get a feel for the delay if it is milliseconds, or multi-seconds.  If it is not instantaneous, is there a way to know when new cartridge ram is mapped in or does the next instruction not become available until the FinalGrom99 is ready?

 

What I am wondering is the ability to embed say all of FunnelWeb into a cartridge or perhaps at least the Editor to free up more memory.  Or, with 4K memory chunks being banked, what resolution of a graphic image could be best displayed at some sustainable frame rate?  Right now, just thinking of ideas. 

 

Beery

Edited November 12, 2019 by BeeryMiller

[HOME AUTOMATION]

If you use GROM as well as RAM/ROM, you wont need a cartridge header on the RAM/ROM image, but will have 480k instead of  512k RAM/ROM.

 

Bytes show up in the real TI just the same as you dropped them on the HEX EDITOR. The image file is just one big space in the HEX EDITOR. But every other >1000 bytes shows up as either RAM or ROM on the TI. So >0000 thru >0FFF in the HEX EDITOR, will come up as >6000 thru 6FFF(ROM) on the TI. While >1000 thru >1FFF in the HEX EDITOR, will come up as >7000 thru >7FFF(RAM) on the TI. >2000 thru >2FFF in the HEX EDITOR, will come up as PAGE 2 >6000 thru >6FFF on the TI. >3000 thru >3FFF will come up as PAGE 2 >7000 thru >7FFF on the TI... and so on.

 

"Would this file then be usable "as is" or does it have to go through some kind of inversion procedure/script to be used by the FinalGrom99?" I'd say ready to go! depending on what "useable" means.

 

Just checked, the 960K image (480K ROM/480k RAM), Plus the 40k GROM, takes exactly 20 seconds to load.

 

I would like to chain images too, at some point. However ralphb's code and comments are somewhat mysterious looking to me. E/A source would be clearer, I imagine. The code looks similar to the "save RAM code" example, however, the "save RAM code" code, I see being used in the MINI MEMORY image, looks different, to me!

 

Supposedly, you have to run a little snippet of scanning code from elsewhere, to read addresses in FG99, and see when loading is complete.

 

EX.

 

https://github.com/endlos99/finalgrom99/blob/master/lib/reload_example.a99

 

 P.S. If you get it figured out, let me know!

 

 

Edited November 13, 2019 by HOME AUTOMATION

[+9640News]

39 minutes ago, HOME AUTOMATION said:

 

Just checked, the 960K image (480K ROM/480k RAM), Plus the 40k GROM, takes exactly 20 seconds to load.

 

Hmmm, ok, thanks for the information and the extra details.  The 20 seconds doesn't quite sound like one would want to chain images for a long video sequence.  More likely, it may be acceptable for putting all the pieces of FunnelWeb into one file.  Add either a sidecar RS232, NanoPEB, or a PEBox with RS232, and one could avoid loading files from floppy type access.

 

Not sure though how many people would find that useful.

Beery

[HOME AUTOMATION]

Yes, even in the HOME AUTOMATION game... 20 seconds is too much down-time. Dividing that 20 sec. up though, gives a more reasonable delay of around 1/6th of 1 sec. per PAGE. That seems to be consistant with what I have observed while loading carts from the selection lists. Not much in life... is perfect for everything! Still, it is a lot of relatively fast memory to have at hand for many purposes.

 

 

    Alex

[Omega-TI]

9 hours ago, BeeryMiller said:

More likely, it may be acceptable for putting all the pieces of FunnelWeb into one file.  Add either a sidecar RS232, NanoPEB, or a PEBox with RS232, and one could avoid loading files from floppy type access.

 

Not sure though how many people would find that useful.

 

Well, after the F18A MkII comes out, and if it can run FunnelWeb, that program could have a resurgence, especially if there is a fast and easy way to load it.

[+9640News]

1 hour ago, --- Ω --- said:

 

Well, after the F18A MkII comes out, and if it can run FunnelWeb, that program could have a resurgence, especially if there is a fast and easy way to load it.

Yeah, some of my same thoughts.  Was thinking along the lines the menu system for Funnelweb would reside in the >6000 to >6FFF memory space, and then based upon a selection, it would move 4K chunks of memory into memory from >7000 to >7FFF where it would previously load.  All it then would need would be a modification to the exit routine back in >6000 to >6FFF.  If each mapped page of >6000 to >6FFF was the same across all 8K banks, then you would not even need to know which page to go to get back into a menu system.

 

It's been years, but I though the Funnelweb source code had been released.  I do not know how many "apps" the system comprised, but I think it would only need modification to return back to the module space instead of where it is going now for each app.  Then, just modify the menu system residing in >6000 to >6FFF that has a table of the memory page each 4K chunk needs to be copied to, reference to which memory page in FinalGrom99 needs to be mapped, length of chunk, and an execution address.

 

Beery

 

 

[Omega-TI]

22 hours ago, OLD CS1 said:

Remaking the game to support 4k paged MiniMemory versus 32k paged SAMS is probably a little more work than it is worth as it would require dividing up the program into 4k chunks (which takes planning) and relocating code to the >7000 space instead of the >2000 and >A000 spaces.  Not impossible and a challenge, but I suspect not practical for an established project.

You may be right in this instance, but I think there would be some appreciative people out there if FunnelWeb or larger items could be converted, as not everyone has a P-Box with a SAMS card installed.  There are some people who only run Nano-PEB's, side-car TIPI's and others using only 32K and a FinalGROM.

[HOME AUTOMATION]

My thinking is that, with some reworking, the MINI MEMORY DSR could 

 

1. Save TI BASIC programs longer than 4k.

 

2 Allow DV/DF RELOCATABLE OBJ CODE files to be reprocessed and stored on FG99's SD card, from EMU, then accessed on a real TI in segments by the @LOADER and run from 32k. Thus bypassing the need for a disk drive on the real TI.

Edited November 13, 2019 by HOME AUTOMATION

[jrhodes]

1 hour ago, HOME AUTOMATION said:

My thinking is that, with some reworking, the MINI MEMORY DSR could 

 

1. Save TI BASIC programs longer than 4k.

 

2 Allow DV/DF RELOCATABLE OBJ CODE files to be reprocessed and stored on FG99's SD card, from EMU, then accessed on a real TI in segments by the @LOADER and run from 32k. Thus bypassing the need for a disk drive on the real TI.

Or some one could just rig a flash card to CS1 somehow?

The MBX seems to be able to do two way communication over it, why not some other device, given the proper amount of hackery.

Edited November 13, 2019 by jrhodes

[HOME AUTOMATION]

I wish I knew more about the MBX, first hand...

 

The cassette port, TI's DSRs use it SEQUENTIALLY only, one could write new ones, but it is a 1 bit A/D, D/A converter built for  serial communication, so, slowest way to go. DV\DF files enjoy RELATIVE access. That's why users load OBJ CODE than save as an image file to load from cassette, but OBJECT CODE probably does LOAD sequentially anyway.

 

There's an audio spectrum analyzer program in Best of 99'er(I believe) that uses the cassette port. I have found that using it can stimulate the mind as to the port's capabilities! I for one, would like to see it do more.

 

[wierd_w]

given the shared grounding between the mic and speaker, I don't think you could do very good fidelity on bidirectional transfers without adding some diodes.

 

It would be neat to see the cassette port abused as a modem (if you could turn the sound off to prevent it on the line), or to get the thing to make arbitrary audio as a PCM device... but I doubt either of those is really possible.

 

**

IF we are going to go crazy and radical though, I would like to see a radical overhaul of the "cassette" system that leverages the joystick port for its 2-wire i2c capabilities. This could either be used to straight up talk directly with an SDCard (which supports i2c according to the spec!), or be used to control a more sophisticated tape deck, to give the cassette loader random access capabilities.

Edited November 14, 2019 by wierd_w