Advertizer module on FG99?

[blackbox]

Hello- now that I have done a great deal of the docs for Advertiser, readily available for emulators- how to get it to the real console? It is gpl only, 8k.

 

The Advertiser module does not have a menu entry, which causes difficulties with Finalgrom, which fails to see it. Is it possible to "fool" Finalgrom with an empty menu entry of some sort, edited into the bin file?? I have tried an SDHC card with JUST Advertiser on it and Finalgrom sees it as an empty card.

 

Is there anyone here with the ability and knowledge to amend the binary currently available for MESS (advertizer.rpk at http://atariage.com/forums/topic/227928-advertizer-phm-3063-what-is-it-and-how-is-it-used/?hl=%2B3063&do=findComment&comment=3037728)

 

Thanks

[atrax27407]

It should be possible to add a short GPL header and make it appear on the menu.

[HOME AUTOMATION]

I think I figued out how to do this about a month ago. Yes FG99 ignores grom power-up header entries. But can be fooled!!! Also because of how the FG99 "fool" works... The TI HEADER sort routine needs to be tricked as well...

I failed to document the trick as I understood it. This had taken me to task... but I had to move on... as my time was limited... I have the working example... somewhere... as I recall, filenames longer than eight chars would keep the trick from working. Figuring out that alone was a super header-ache.

The trick involves the addition of a rom file and a combination of menu entries(one being a useless dummy) and a power-up header entry... and a little branching back and forth. The user selects the correct entry(not the dummy) from the FG99 menu... The program may run properly... then QUIT or FG99 RESET BUTTON will enter the power-up routine normally.

 

I don't have or use GPL or its editors... I had to use a hex editor and or EASY-BUG to add the GPL XML vector(procedure) branch... I looked up the GPL op-codes on thierry's pages.

I'll try and look into this later if no other solution develops...

The first 6 bytes seem foreign... next I can recognize the standard header.

I'm looking at this with TI99dir... I'll have to open it with a HEX-EDITOR and remove the 6 bytes to analyze the header fully.

[blackbox]

The tool showcart indicated "AA" missing, which wasn't, but the python script seemed to be looking for a translation routine, so I added a second grom to the bin file by appending >aa >81 >00 >00 >00 >00 >00 >00 which caused showcart.py to indicate "autostart highgrom" - but the fg99 still showed the card as empty....

 

So a little extra is needed.... I think I need another hint. regards Stephen

[HOME AUTOMATION]

This is a little different... I see there is no main program gui.
perhaps there is an initialization program... there appears to be an entry point. I'm using CLASSIC99 and MESS 0.79. The .DSK image was incompatible... next the files wont load into basic. Some CALLS start to execute but halt with... something like "BAD INITIALISATION".

any docs ready??? could help!

[blackbox]

Working ADVERTISER in FG99!

 

Here we are then,,, one that works (sort of...)

 

First- docs online at:

shawweb.myzen.co.uk/stephen/3063.htm

 

Because this module appears to do nothing! I wonder how many have been thrown away!

 

Here is a modified bin, as FG99 wants an autostart, it has an menu entry added which goes into console rom - you get a purple title screen on my 4a, press a key and select either of two TI Basic options. It then works. The strange title screen confirms something has happened and two TI Basic options give further comfort. Will not work on a TI99/4, I don't think the vn 2.2 should have a problem.

 

If you do not have a disk controller, you initiallise with CALL AD and try typing CALL MUSIC(7) for fun.

 

Can anyone improve on this before I add it to the main FG99 thread? Thanks.

 

Stephen

advertG.bin

[blackbox]

READ ME- modified bin file for easier start up.

 

Modified the bin file to make it easier- and make it compatible with the 99/4. Instead of a jump to TI Basic, we now jump to the Title Screen.

 

Place the bin file below on your SDHC card in the usual manner.

 

- select 2 for Finalgrom

- select ADVERTISER

 

IF you have no disk controller, the screen will turn purple (the Advertiser module does this) and a TI Title screen with purple borders appears. If you have a disk controller you don't get the purple. The purple tells you that you do not need to use CALL FILES.

 

Select 1 or 2 and you will get a BASIC READY.

 

With a disk controller- type CALL FILES(9) then NEW then CALL AD then CALL MUSIC(7)

 

With no disk controller- from the command line type CALL AD then CALL MUSIC(7)

 

enjoy Stephen

 

advert8g.bin

Edited November 15, 2018 by blackbox

[HOME AUTOMATION]

Is that another header I see at G>8000! I hadn't thought of that (yet ). Can this really be improved on? I think you have it all wrapped up here! I Hope my observations helped(a little)? I had forgotten about the need to do a NEW after CALL FILES(9).

 

This is really cool X2.

 

congrats...

[blackbox]

Yes, the TI99/4a is quite happy to have the header in Grom2 (or 3...) - and yes thanks your observations did indeed provide the needed nudge!

 

This seemed to be such a very full module that using Grom 2 seemed the way to go.

 

I have disassembled odd bits of the module, and the behaviour of adding purple borders to the title screen to confirm the module was available (when no disk controller was attached) was so cool. If you see a purple border, no need to do CALL FILES. Neat.

 

We can't blame poor old FG99, this module really was quite unique, and I expect the lack of normal behaviour led to several being binned as faulty.

 

regards

 

Stephen

Edited November 15, 2018 by blackbox

[HOME AUTOMATION]

Thanks back, I,m enjoying this as well, I want the sound lists...

 

a little OT: I ran into a little glitch on the TI or disk DSRs,
that is... after doing a CALL FILES, RESEQUENCE crashes.
I think I might have run into this before.

[blackbox]

Thanks back, I,m enjoying this as well, I want the sound lists...

 

a little OT: I ran into a little glitch on the TI or disk DSRs,

that is... after doing a CALL FILES, RESEQUENCE crashes.

I think I might have run into this before.

 

 

I think it is a VDP collision - we have a lot less VDP memory after CALL FILES(9) and I'm sure RES wasn't too well protected when resequencing long TI Basic programs. Generally not a problem with XB.

 

The sound lists are in there! For BEEP and HONK it takes the code from the console.

BEEP EQU >0034

HONK EQU >0036

There is a lot of DATA at the end of the GROM which I haven't really done much with - I suspect sound may be around the area 7B98-7F07 ish, but it gets rather confusing.

 

Stephen

[RickyDean]

It was interesting to see that end piece on your page Steven:

 

The sample seen has the following chips:

2 x 4k eprom TMS2532JL,
4x synchonous 4 bit binary counters SN74LS161,
2 x quadruple 2 input positive OR gates SN74LS32N
and a dual decoder/demultiplexer SN74LS139N.

[+FarmerPotato]

 

The sound lists are in there! For BEEP and HONK it takes the code from the console.

BEEP EQU >0034

HONK EQU >0036

There is a lot of DATA at the end of the GROM which I haven't really done much with - I suspect sound may be around the area 7B98-7F07 ish, but it gets rather confusing.

 

Stephen

Sound lists? Here you go.

The linked code, sndsrch.c, guesses at what portions of a file are sound lists. It found 8 potential sounds. See advertsnds.txt for source. (I did not test the sounds.)

There are some variants in the output file, because some guesses overlap. The program prints alternates

in cases where a byte might be interpreted as either a count or a sound chip command. You will have to untangle them.

It also prints 2-3 stray bytes in "holes" between almost contiguous sound lists. Several of these holes

are >7E,>82. Is that GPL for play sound?

Oh I think I get it.. this is at grom base 6000. S$1E82 is another list for silence then a tone.. 7E82 sure appears in there a lot. Hmm.

 

Example:

S$1E16 BYTE 7,>8E,>12,>90,>A8,>16,>B0,>DF,40 
       BYTE 2,>9F,>BF,30
       BYTE 6,>8E,>12,>90,>A8,>16,>B0,60
       BYTE 4,>82,>13,>AD,>16,8
       BYTE 6,>87,>13,>91,>A2,>17,>B1,8
       BYTE 4,>8B,>13,>A7,>17,8
       BYTE 6,>80,>14,>92,>AD,>17,>B2,8
       BYTE 4,>85,>14,>A3,>18,8
       BYTE 6,>89,>14,>94,>A9,>18,>B4,8
       BYTE 4,>8E,>14,>AF,>18,8
       BYTE 6,>83,>15,>96,>A4,>19,>B6,8
       BYTE 4,>88,>15,>AA,>19,8
       BYTE 6,>8D,>15,>99,>A0,>1A,>B9,8
       BYTE 4,>82,>16,>A6,>1A,8
       BYTE 6,>88,>16,>9C,>AC,>1A,>BC,8
       BYTE 0


M$1E80 BYTE >7E,>82

S$1E82 BYTE 3,>9F,>BF,>DF,0
       BYTE 3,>86,>0D,>93,10
       BYTE 0

https://raw.githubusercontent.com/olsone/forti/master/sndsrch.c

 

https://raw.githubusercontent.com/olsone/forti/master/advertsnds.txt

Edited November 15, 2018 by FarmerPotato

[blackbox]

There are some variants in the output file, because some guesses overlap. The program prints alternates

in cases where a byte might be interpreted as either a count or a sound chip command. You will have to untangle them.

 

 

TI did use overlapping sound lists, so that is not abnormal. Tunnels of Doom has them. Generally in gpl the code passes an address which contains a sound list address (indirect addressing). The sound lists are transferred to scratch pad ram for the GPL IO instruction to use them.

 

It also prints 2-3 stray bytes in "holes" between almost contiguous sound lists. Several of these holes

are >7E,>82. Is that GPL for play sound?

 

7E82 is an address- Byte 0 followed by Byte 7E82 means JUMP TO 7E82, which appears to be silence- duration 0 is stop.

See your list:

S$1E82 BYTE 3,>9F,>BF,>DF,0
BYTE 3,>86,>0D,>93,10
BYTE 0

Good useful list there- add 6000 to get the GROM address - the lists check out fine.

 

I saw a table of 9 sound lists-table at 7B98:

A table of sound lists at 7B98, which gives sound lists starting at 7BAA, 7C4A, 7CFA, 7D2D, 7D91, 7D57, 7E16, 7CA8, and 7E83.

 

Each list contains a length code, that number of command codes, and a duration.

 

No reason there shouldn't be other sound lists in there.

 

 

Well done! Nice bit of code.

 

Stephen

[HOME AUTOMATION]

I love it when this happens... I was just saying... in a general sense, I do collect sound fx ...for my HOME AUTOMATION CONTROLLER design.

Thanks for all the efforts. I might not have gotten back to it.

From the name sndsrch.c I imagine this is written in C. For the life of me... I haven't been able to get a clue from looking C code over... how it operates. Is that C? I have been wanting to understand how a program called "talkie" operates. It can synthesize TI speech from the LPC data. I thought I might feed it streams of ROM data, so as to discover the start points and length of LPC strings. I imagine that rather than choke up or crash, it would hopefully just produce noise during gaps where foreign data exists. I have wanted to isolate these LPC strings some of which I believe are sound effects, from this ROM for many years now... but the point I am at in my project hasn't justified that yet. I would like to get talkie to run from my RPI(TIPI)... I hope I'm not diluting this topic too much... any ideas on sources of sound data for TI... or a good start point to learn C would be helpful to me.

[+FarmerPotato]

I love it when this happens... I was just saying... in a general sense, I do collect sound fx ...for my HOME AUTOMATION CONTROLLER design.

 

Thanks for all the efforts. I might not have gotten back to it.

 

From the name sndsrch.c I imagine this is written in C. For the life of me... I haven't been able to get a clue from looking C code over... how it operates. Is that C? I have been wanting to understand how a program called "talkie" operates. It can synthesize TI speech from the LPC data. I thought I might feed it streams of ROM data, so as to discover the start points and length of LPC strings. I imagine that rather than choke up or crash, it would hopefully just produce noise during gaps where foreign data exists. I have wanted to isolate these LPC strings some of which I believe are sound effects, from this ROM for many years now... but the point I am at in my project hasn't justified that yet. I would like to get talkie to run from my RPI(TIPI)... I hope I'm not diluting this topic too much... any ideas on sources of sound data for TI... or a good start point to learn C would be helpful to me.

 

 

I have a mind to do a search program for LPC codes, against the Gauntlet ROMs for starters (it had a TMS5220.)

 

I'll have to defer working on a TI sound survey for a bit. You can lift from games that have source code, and there is a SNDTEST collection that TI did (that's another story).

 

As for learning C, I started with Clint Pulley's c99 tutorial and a bunch of Dr Dobb's magazines, but I would not recommend that. I am grateful for the Brian Kernighan books:

 

The C Programming Language by Brian Kernighan

The UNIX Programming Environment by Kernighan and Pike

The C Standard Library by P.J. Plauger

 

That was a long time ago, but, you would absorb more knowledge from that course than many others.

 

These days we have fancy stuff like https://www.learn-c.org