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

[HOME AUTOMATION]

Because of the 1 bit only sampling, FM, yes... AM, no! I wonder if speech would even be intelligible.

 

I think It can make MARK and SPACE tones, max speed... I dunno.

 

I2c, sounds cute for storage, but the optocoupler interface blocks all D.C., ...not sure how to overcome, IR remotes seem to though.

 

Top of the line units, I proposed using a couple of these to an audio dubbing client whom copied live concert tapes(punk rock), for sale.

 

https://bytecollector.com/dg_phideck.htm

 

But I ended up rewiring the heads on a cheaper, dual reverse, dual deck unit , to make high speed mono copies. I think we got the time down to about 11 min. one pass to copy both sides of a 90 Min. (C-90) tape.
 

Edited November 14, 2019 by HOME AUTOMATION

[wierd_w]

I2C on Ti99/4A

http://www.stuartconner.me.uk/ti/ti.htm#i2c_interface

 

SDCard in SPI mode

http://elm-chan.org/docs/mmc/mmc_e.html#spimode

 

 

Already been done; Just needs storage stack.

 

 

Or did you mean i2C on the cassette header? (I doubt you could do that reliably...)

 

Wait... How fast can you joggle the tape-hold signal? If you use tape-hold as D0, the audio signal output as the SCLK, and the audio input as D1....

Edited November 14, 2019 by wierd_w

[+FarmerPotato]

19 hours ago, jrhodes said:

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.

More likely both joystick and cassette.

 

I found a program to connect the 4A and the Magic Wand Speaking Reader to speak allophones. It used a cable from the cassette and joystick ports. I no longer have the cable, but it was 4 direct wires attached to a RJ11 and 2 DB9 connectors. (I think Mike Reed made it at TI?) I'm going to try to reconstruct it now that I have the object code (not source) that used it.   I think though that this was write-only. 

 

I've implemented FAT32 on SD card though 4 pin SPI in FORTH. It's the standard SD card module used in FlashROM etc. I2C is more difficult: SPI is the way to go for one device like an SD.

 

Found the MWSR code because I returned to an old, corrupted disk of speech demos from TI that I locked in a cabinet in 1986 and lost the key for. (weird, huh?). I read the disk with Kryoflux and was able to get some files off it.  Working on speech coding here, so it was worth returning to.

 

 

[+FarmerPotato]

12 hours ago, wierd_w said:

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.

i2c is a bad idea, for the reasons Stuart pointed out in his implemtation.

 

SPI is much easier.

[HOME AUTOMATION]

2 hours ago, wierd_w said:

I2C on Ti99/4A

http://www.stuartconner.me.uk/ti/ti.htm#i2c_interface

 

SDCard in SPI mode

http://elm-chan.org/docs/mmc/mmc_e.html#spimode

 

 

Already been done; Just needs storage stack.

 

 

Or did you mean i2C on the cassette header? (I doubt you could do that reliably...)

 

Wait... How fast can you joggle the tape-hold signal? If you use tape-hold as D0, the audio signal output as the SCLK, and the audio input as D1....

Stuart Conner's page is getting better all the time.

 

The Electronic lives page looks like a good reference also.

 

I guess I didn't realize you were talking about using both ports together.

Not sure about the top speed of switching the 9901 outputs(which drive the CSx motor controls) on/off, but I would guess less than 100kHz.

 

I often Tesla/Edison it instead of crunching the numbers.

 

Ex.

I haven't been able to afford much time or heart with my TI this year...
But... I spent an hour or less on an idea that struck me recently.

I thought I would try to record/reproduce IR remote control pulses(PWM), by using a 9901 input pin toggled by the IR LEDs output, counting the number of cycles between pulses with an INC instruction, than reversing the process.

 

       LI   R6,>B000
TEST   CLR  R5
CHECK0 TB   17
       INC  R5
       JNE  CHECK0
       MOV  R5,*R6+
       BLWP @
       INC  R0
       CLR  R5
CHECK1 TB   17
       INC  R5
       JEQ  CHECK1
       MOV  R5,*R6+
       JMP  TEST

 

The output voltage from the remote was below the 9901s sense capability. After running it through an optocoupler to correct the voltage... the longest count I could read between pulses was 5 to 7,  the shortest  1 to 3. The IR signal is mostly 38k pulses, I imagine. I don't think that kind of resolution will be accurate enough to work though.

 

on an aside... Next I'll try to count the pulse durations w/o the 38k carrier, I believe that the carrier could be generated externally and just stomped on by the TI.

 

Edited November 14, 2019 by HOME AUTOMATION

[apersson850]

That code can't work. INC affects the status bits, so the following JNE will consider the result of the incremented value vs. zero, not the result of the TB instruction.

[HOME AUTOMATION]

22 hours ago, wierd_w said:

I2C on Ti99/4A

http://www.stuartconner.me.uk/ti/ti.htm#i2c_interface

 

SDCard in SPI mode

http://elm-chan.org/docs/mmc/mmc_e.html#spimode

 

 

Already been done; Just needs storage stack.

 

 

Or did you mean i2C on the cassette header? (I doubt you could do that reliably...)

 

Wait... How fast can you joggle the tape-hold signal? If you use tape-hold as D0, the audio signal output as the SCLK, and the audio input as D1....

Sorry about the wrong code, it was meant to  clarify and qualify my result. Alas, that was merely the original scrap I started out with. I lost whatever I had done, still can't find... Now that I'm back on track... I'm feeling less certain about what the upper frequency threshhold is for the 9901's I/O ports. Sorry about that.
 

[HOME AUTOMATION]

1 hour ago, apersson850 said:

That code can't work. INC affects the status bits, so the following JNE will consider the result of the incremented value vs. zero, not the result of the TB instruction.

You just made a new friend. Thanks for taking the time!

 

Yes, I noticed last night that I uploaded the wrong code. Maybe the code I actually used was flawed(not sure). I worked on this last night, and this morning, I had quite a time debugging it(it's been a while)! I added a couple improvements, like clearing the "capture space(>B000)" first, and auto-exiting with the JLT instruction(adds a slight delay to accuracy).

 

I've switched to sampling the output from the IR receiver(no more, 38kHz). I believe I am getting larger and more consistent pulse duration numbers back now. They look usable to me!

 

I'll need to pull the IR receiver module off the PCB to send pulses back since the module is usually outputting a logical LOW voltage level. Than we shall see, as it were!

 

First I'll probably go back and retest the remote's output again!

 

       AORG >7D00
       DEF REMOTE   
REMOTE CLR  R0
       CLR  R12
       LI   R1,>3FFA
       LI   R6,>B000
NEXT   MOV  R0,*R6+
       DEC  R1
       JNE  NEXT
       LI   R6,>B000
WAIT   TB   17
       JEQ  WAIT
TEST   CLR  R5
CHECK0 INC  R5
       TB   17
       JEQ  CHECK0
       MOV  R5,*R6+
       CLR  R5
CHECK1 INC  R5
       TB   17
       JNE  CHECK1
       MOV  R5,*R6+
       CI   R6,>B0FF
       JLT  TEST
       RT
       END 

 

[apersson850]

1 hour ago, HOME AUTOMATION said:

You just made a new friend. Thanks for taking the time!

       AORG >7D00
       DEF REMOTE   
REMOTE CLR  R0
       CLR  R12
       LI   R1,>3FFA	A lot of bytes to clear
       LI   R6,>B000
NEXT   MOV  R0,*R6+		Clear a word at a time
       DEC  R1			But count bytes, so we clear >B000 - >2FF4. Should be DECT
       JNE  NEXT
       LI   R6,>B000
WAIT   TB   17			Wait as long as bit is zero
       JEQ  WAIT
TEST   CLR  R5			Now start measuring
CHECK0 INC  R5
       TB   17
       JEQ  CHECK0		Count as long as it's zero, but we know already it's not, or we wouldn't be here
       MOV  R5,*R6+
       CLR  R5
CHECK1 INC  R5			So we end up here immediately. Thus this part could come first, CHECK1 before CHECK0
       TB   17
       JNE  CHECK1
       MOV  R5,*R6+
       CI   R6,>B0FF	Much smaller than the buffer that's cleared
       JLT  TEST
       RT
       END 

 

You're welcome. I added some comments to your code.

[HOME AUTOMATION]

Once again, appreciated!

 

Good help is so hard to find! I won't be able to pay much though...

...unless this works and really catches on!

 

My code is usually still in some state of abstract tinkering...

 

I'll see if the numbers come up any better!

 

The more I look at these numbers from the receiver, the more I recognize the pattern from the tests I'd done previously on a similar remote. Maybe that's a good sign!

     W.I.P. 

[HOME AUTOMATION]

So. The first word looks a little more sensible anyway. I really do need to use my Scott Foresman carts more... I meant to clear up to >FFFA, thanx.

 

Now that the numbers indicate 10 or more instructions can execute during a pulse, I wonder if I can get a 9901 timer in on this if needed(never used before). I may be adding an extra one inside the Speech Synth to drive this thing as well as providing an interface for my HOME AUTOMATION system. I've been considering CRU base >0400.

 

       AORG >7D00
       DEF REMOTE   
REMOTE CLR  R0
       CLR  R12
       LI   R1,>4FFA
       LI   R6,>B000
NEXT   MOV  R0,*R6+
       DECT  R1
       JNE  NEXT
       LI   R6,>B000
WAIT   TB   17
       JEQ  WAIT
TEST   CLR  R5
CHECK1 INC  R5
       TB   17
       JNE  CHECK1
       MOV  R5,*R6+
       CLR  R5
CHECK0 INC  R5
       TB   17
       JEQ  CHECK0
       MOV  R5,*R6+
       CI   R6,>B0FF
       JLT  TEST
       RT
       END

Turns out the sequences are less than 256 bytes. I have to press twice or hold key down to get there.

 

 

The Stork brought me another little surprise today, it fits! ...sort of.

 

[HOME AUTOMATION]

So, would you believe it... it actually worked... and, on the first try!

...that's more like it!

 

So, I thought I'd post the code and the scans... so others can recreate... or not.

 

Also to exemplify the convenience of using a PAGED MINI MEMORY image...

 

The output program...

       AORG >7D00
       DEF REMOTE   
REMOTE CLR  R12
       SBO  16
       LI   R6,>7E00
MARK   CLR  R5
       MOV  *R6+,R5
CHECK1 SBZ  16
       DEC  R5
       JNE  CHECK1
SPACE  CLR  R5
       MOV  *R6+,R5
CHECK0 SBO  16
       DEC  R5
       JNE  CHECK0
       CI   R6,>7E94
       JLT  MARK
       RT
       END

 

I guess this would be better off on the DEVELOPMENT sub-forum... but... I didn't want to break the continuity.

 

 

In the picture I have tapped the output from the IR decoder module and connected it to the 9901 I/O port, that's controlled by CRU bit 17 and read with the TB instruction. The associated input to the player's IC, is connected to the 9901 I/O port, that is controlled by CRU bit 16 and written to by the SBO/SBZ instructions.

 

 

 

In the .BIN image... Execute >1100 to scan a button. Execute >1180 to send a code to the player. You'll need to set the capture buffer addr. and replay buffer addr. manually. One of the scans is shown at >1200. The codes for all the buttons, scanned from left to right and top to bottom are stored on PAGE 2 in both ROM/RAM.

 

The scans for all 21 buttons on the remote, come to a whopping 3kb. 

I have found out that the word length delays at the start and end of scans can be dropped.

Trying to round the byte values off however, resulted in failure. Otherwise accuracy seems to be 100%. I suppose that byte values could be used instead of word values, but might need re-scanning or adjustment. Wow!

 

The two different players, use the same codes, but in a slightly different arrangement.

Find similar units on E-bay, by searching "bluetooth mp3 remote", some units have recording and could possibly hold cassette based files. Track #'s can be dialed in! I saw one unit with AM/FM and FLAC. These are also Bluetooth speakers, so you can access your cell-phone's music and take calls too. However, the units I tested have only pre-amp level outputs, so, need an external audio amplifier!

 

         H.A. 

 

                                           remote codes BIN.zip

 

 

Edited November 18, 2019 by HOME AUTOMATION

[fablug]

Hello, I found this interesting thread and I made some experiments using your MINIMEMORY image (256 kb) on my FG99

I make apologies for my ignorance ☺️ but there are some things I don't understand.

First, I check the page 1 content and I found the line-by-line assembler and Lines demo.

Then I went to TI-BASIC and wrote CALL LOAD (26626,0) making a page swap.

Then I did CALL INIT, wrote a few lines of a BASIC program.

SAVE MINIMEM and so far it worked fine.

(if I recall OLD MINIMEM in page 2 I would get my BASIC program back, If I CALL LOAD (26624,0) the TI99 then the line-by-line assembler and LINES program it's back again in memory.

Now...  some questions...

 

1) the new option SAVE MEMORY in the main menu doesn't work. If I do it, the page1 is reloaded from start and the other pages erased. Shouldn't it save the content of all pages on the SD CARD in the FG99 ? I checked on the SD card if a new file was written or the image modified but nothing has happened. I understood that the new command would write a file with the contents of all pages and if you swich the TI99 off and on again, you would find your content again. Is it correct?

2) I don't get how you can write a CALL LOAD at 26624...26626... where ROM is supposed to be. And indeed if I do a CALL PEEK after my CALL LOAD the content of the memory is'nt changed. Is there a special interrupt which intercept this command and make the page swap?

3) Same question about the address >6000 where ROM is supposed to be also. And in case it works the same way of point 2 What can I do with GROM swap? What use is for?

4) FG99 page says that FG99 could work in advanced mode putting a "R" in >6000 to write on SD card (and again how could it work on a ROM address which is supposed to be not changeable)

Too many things I am not able to understand 😀  I would be glad to have some more info.

Thank you and congratulations for your excellent work!

Fabrizio

On 11/12/2019 at 12:11 AM, HOME AUTOMATION said:

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.

 

Edited October 6, 2022 by OLD CS1
Fixed. Welcome aboard.

[HOME AUTOMATION]

Too many things I am not able to understand 😀  I would be glad to have some more info.

 

Don't feel bad, this(paging) is a trying subject.

 

1. Although the Version #, has not been incremented, the FinalGROM 99's, .AVR update(Download 1.3), has been modified a couple times(by ralphb) in order to accommodate the SAVE MINIMEMORY option. The original Version, did not support this feature, so you may need to update.

 

2.  Previously, I had referred to 26624, as PAGE 1. I was new to memory paging at that time. I now, more properly, refer to this as PAGE 0.

 

You don't specify where you CALL PEEK, or what value(s) you write/read. So, I'm guessing here...

 

Addresses 26624, 26626, are HEX addresses >6800, >6802. Writing to these addresses, will not change the value(s) stored at these address(s)(as it's virtual ROM). Instead, writing to 26626, will change the address range >7000->7FFF, from PAGE 0, to PAGE 1. Whereas writing  to 26624, will return the address range >7000->7FFF, from PAGE 1, to PAGE 0.

 

When using the RAM/ROM, feature of FG99("R"), there are two separately switched groups of pages.

 

Up to 128, ROM PAGES, resident at a range between >6000->6FFF, are switched by writes to >6000->6FFE.

Up to 128, RAM PAGES, resident at a range between >7000->7FFF, are switched by writes to >6800->68FE.

 

The least significant bit is ignored.

 

3. GROM doesn't use paging. However, you can use GRAM. With GRAM, you could copy data/GPL PROGRAMS(new/existing), from ROM/RAM, to GRAM, and execute with the GPL INTERPRETER.

 

You could alter the GPL HEADER, on-the-fly, then reenter the TITLE SCREEN, or cart. selection menu.

 

There are other creative uses, I'm sure!

 

4. The "R", alone, does not cause writing on the SD card. The "R", engages the dual PAGE-SWITCHING behavior, with the upper 4K block presented as pre-loaded RAM.

 

The "R", needs to be in the HEADER. If your image includes GROM, than the "R", need only be there. Use an "X", for GRAM.

 

Since there is no way to write to ROM/GROM, the initial "R", or "X", has to be included in the initial .BIN image. This is perhaps best accomplished with the use of a HEX-EDITOR.

 

Writing to the SD card, is only a bit more complicated. But, that is exactly what the "SAVE MEMORY" feature, from the selection menu, does.

Edited October 6, 2022 by HOME AUTOMATION

[Asmusr]

11 hours ago, fablug said:

2) I don't get how you can write a CALL LOAD at 26624...26626... where ROM is supposed to be. And indeed if I do a CALL PEEK after my CALL LOAD the content of the memory is'nt changed. Is there a special interrupt which intercept this command and make the page swap?

When you write to an address occupied by ROM in order to swap a page, the cartridge hardware sees the write and changes the page. The ROM itself doesn't support writes so it ignores it.

[fablug]

4 hours ago, HOME AUTOMATION said:

Too many things I am not able to understand 😀  I would be glad to have some more info.

 

Don't feel bad, this(paging) is a trying subject.

 

1. Although the Version #, has not been incremented, the FinalGROM 99's, .AVR update(Download 1.3), has been modified a couple times(by ralphb) in order to accommodate the SAVE MINIMEMORY option. The original Version, did not support this feature, so you may need to update.

 

2.  Previously, I had referred to 26624, as PAGE 1. I was new to memory paging at that time. I now, more properly, refer to this as PAGE 0.

 

You don't specify where you CALL PEEK, or what value(s) you write/read. So, I'm guessing here...

 

Addresses 26624, 26626, are HEX addresses >6800, >6802. Writing to these addresses, will not change the value(s) stored at these address(s)(as it's virtual ROM). Instead, writing to 26626, will change the address range >7000->7FFF, from PAGE 0, to PAGE 1. Whereas writing  to 26624, will return the address range >7000->7FFF, from PAGE 1, to PAGE 0.

Thank you! Now it's more clear. I still have some little issues and I sent you a copy of my MINIMEM image where 2 programs have been saved but I can only reload one.

 

4 hours ago, HOME AUTOMATION said:

When using the RAM/ROM, feature of FG99("R"), there are two separately switched groups of pages.

 

Up to 128, ROM PAGES, resident at a range between >6000->6FFF, are switched by writes to >6000->6FFE.

Up to 128, RAM PAGES, resident at a range between >7000->7FFF, are switched by writes to >6800->68FE.

 

The least significant bit is ignored.

 

3. GROM doesn't use paging. However, you can use GRAM. With GRAM, you could copy data/GPL PROGRAMS(new/existing), from ROM/RAM, to GRAM, and execute with the GPL INTERPRETER.

 

You could alter the GPL HEADER, on-the-fly, then reenter the TITLE SCREEN, or cart. selection menu.

 

There are other creative uses, I'm sure!

 

4. The "R", alone, does not cause writing on the SD card. The "R", engages the dual PAGE-SWITCHING behavior, with the upper 4K block presented as pre-loaded RAM.

 

The "R", needs to be in the HEADER. If your image includes GROM, than the "R", need only be there. Use an "X", for GRAM.

 

Since there is no way to write to ROM/GROM, the initial "R", or "X", has to be included in the initial .BIN image. This is perhaps best accomplished with the use of a HEX-EDITOR.

 

Writing to the SD card, is only a bit more complicated. But, that is exactly what the "SAVE MEMORY" feature, from the selection menu, does.

Ok I got the differences and how the FG99 works
I also understand that you need to modify the image file (BIN) to include the R o X option otherwise there 's no way to change it by command line or CALL LOAD subprogram but at the moment I think I would concentrate on making the PAGE switch for RAM working. I will investigate more on this topic 🙂
Thank you again.

[fablug]

2 hours ago, Asmusr said:

When you write to an address occupied by ROM in order to swap a page, the cartridge hardware sees the write and changes the page. The ROM itself doesn't support writes so it ignores it.

Ok I think I got it now it's a bit clearer so it's a virtual ROM and FG99 intercepts that "special address" and make the page switch. I was considering the ROM under a theoretical point of view and I couldn't figure how you could write to a ROM address that can not change its value.
Thank you 😊

[+acadiel]

On 11/12/2019 at 8:08 AM, 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.

Yep, and there's also the ROMDsk option that Fred Kaal and I have spec'd out that allows disk cartridge ROM to be used as a ROM disk storage.  Virtual floppy storage only limited by ROM size (512K ROM on the UberGROM board)