F18A programming, info, and resources

[matthew180]

In the original color mode, the pattern pixel ('0' or '1') selects between one of two colors from the color table. If either color value from the color table is zero, then the backdrop color is used (i.e. the pixel is transparent). This is why the 9918A has color black as the second color (see pg. 2-17 in the 9918A data sheet), because you need a way to differentiate between transparent and a color. If you want to use sixteen *colors* without a transparent, then color zero needs to be your black and you need to set the backdrop color (via VR7) to black so that the zero-index transparent pixels show as black.

 

Using the palette above in post #570, just set VR7 to >x0 (the low nibble needs to be 0) and it should work as expected.

[+InsaneMultitasker]

Using the palette above in post #570, just set VR7 to >x0 (the low nibble needs to be 0) and it should work as expected.

Setting VR#7 like you suggested seems to have done the trick. The palette is working now, and I've been able to test a few routines against it! The index magic is still a bit of a mystery to me Thank you and Rasmus for helping me resolve this!

[matthew180]

I'll see if I can get something written up that explains the color selection.

[timofonic]

Are there guides and communities to make non-TI99 users program for F18A?

[matthew180]

There are some people writing games for the ColecoVision that take advantage of some of the F18A's enhanced features.

 

The F18A itself is not particular to any one system (like the original VDP), and thus programming it is the same no matter what system. Most of the examples here should apply to any system since they explain how to program the F18A, and not specifically the 99/4A. If you can program the 9918A on your system of choice, then you can program the F18A and use the info here. Asking specific questions is typically the best.

 

The 99/4A is probably the strongest community around the F18A, the ColecoVision would be second. The MSX1 community never really showed any interest in the F18A (I'm not sure why), and I don't know of any MSX1 software that uses its features.

 

There are a few people using the F18A in home-brew systems or other computers, but mostly for the VGA output AFAIK.

[RXB]

Hi everyone. I hope we are all well.

 

Just a quick question.

 

Is there any chance of a really clever TI guru making a version of Extended Basic that has CALL commands to support the F-18A?

For instance, we could have a special CALL COLOR command that can have extra parenthesis to support more colours in the 8x8 character block?

Probably not what anyone was expecting or thinking, but it would be really good. Either that, or I could bugger off and learn Assembly.

Got a F18 now so I am working on that one.

[Omega-TI]

Got a F18 now so I am working on that one.

 

Make it 80 column and I'll make RXB my one and only ExtendedBASIC.

[RXB]

 

Make it 80 column and I'll make RXB my one and only ExtendedBASIC.

Now that would require a huge rewrite of entre XB as it is 32 x 24 character designed.

Here is a problem XB uses 8 x 8 characters, while Text characters are 6 x 8 so not a single previous XB program would ever be compatible.

The screen would be skewed and odd at best not to mention sprites are 8 x 8 not 6 x 8 so complicates even more graphics modes.

 

Now what I was looking at was F18 Graphics output with sprites and a Edit mode of 80 columns then switch to 32 x 24 in program mode.

So at least you can use 80 column mode in Edit Mode taking advantage of F18 ability to do 80 columns.

 

This would be doable and not require as much of a complete rewrite of the entire XB GPL code and ROMs.

[TheMole]

Now what I was looking at was F18 Graphics output with sprites and a Edit mode of 80 columns then switch to 32 x 24 in program mode.

So at least you can use 80 column mode in Edit Mode taking advantage of F18 ability to do 80 columns.

 

This would be doable and not require as much of a complete rewrite of the entire XB GPL code and ROMs.

 

80-column edit mode would be awesome!

Senior_falcon has also created an 80-column runtime library for XB, so he could maybe help out.

[RXB]

This is why I was excited to hear about the F18 MK2 as what is needed is more VDP memory and a way to speed up VDP graphics.

More sprites per line is great, but with same amount of memory it is like putting a turbocharger on your car, but with a governor so the get little benefit.... very unimpressive.

 

First F18 step is add in 80 Column Text for XB, second step is F18 MK2 and addition graphics available.

 

I think I am going to be forced to use another bank of GROM to do this. I already did the research and released a multiple Bank GROM RXB version for REA.

 

It used >9800 base GROM and another bank of GROM it would find in one of the other 16 banks, so you could move it to any bank and it would find each other.

 

Or maybe one of the new carts like FinalGROM, but I do not know much about it yet, will have to get one to find out.

Edited August 10, 2018 by RXB

[Asmusr]

There are a few features of the F18A that you could support without reserving any additional VDP RAM. Changing the color palette and smooth scrolling the entire screen are two examples. 80 color mode requires more RAM and you need to change some pointers to reserve that. Still quite possible within 16K.

 

The F18A MK2 should eventually make it possible to leave the lower 16K VDP RAM alone and work with a second screen that uses one of more of the additional RAM banks. That should make BASIC integration a lot easier.

 

http://js99er.net is currently the only emulator that has almost complete F18A support.

Edited August 10, 2018 by Asmusr

[RXB]

Here are ton of problems to deal with.

 

1. No way could you test a character from EDIT MODE type: CALL CHAR(65,"FF18FF18FF18FF18") as EDIT MODE would crash as TEXT MODE is 6 x 8 not 8 x 8.

2. Any command that used CALL COLOR from EDIT mode would crash as the VDP memory map is not the same for TEXT MODE as GRAPHICS MODE.

3. Even CALL CLEAR from EDIT MODE would crash, or at least behave strange by only clearing part of screen.

4. Same goes for HCHAR, VCHAR, GCHAR, DISPLAY AT(row,col), PATTERN, SCREEN and of course anything to do with SPRITES.

 

From EDIT MODE you could LOAD and LIST XB programs and EDIT PROGRAMS, but never test a line in EDIT MODE. ONLY PROGRAM MODE!

 

This would work in RXB with F18 but only because no Graphics are needed:

FOR X=1 TO 10 :: Y=Y+1*X :: NEXT X

This would execute from the CRNBUF (Line Crunch Buffer) so no conflicts would result as no graphics are changed.

 

The only other option I can see is to add a third mode to XB as currently there is EDIT MODE and PROGRAM MODE, but where to get that much memory is a mystery????

[Casey]

I may be hopefully confused with the problem you are describing above, so please forgive me if this sounds ignorant. But the 99/8's Extended BASIC was able to handle some of what you described. I realize that may be completely irrelevant since you aren't using Extended BASIC II as your codebase. But you can shift from 32x24 mode to 40x24 mode with CALL GRAPHICS(2) and then CALL CHAR(65,"FF18FF18FF18") works just like you would expect it in 32x24 mode.

 

It may be impossible to do this with your code base just because of the starting point of it, and I also don't know if the GPL source code of Extended BASIC II is even available to look at, but it sounds like TI was able to make whatever you are describing above work.

 

Like I said, it may be completely impossible without rewriting the whole RXB from scratch, so feel free to tell me to go away

[RXB]

I may be hopefully confused with the problem you are describing above, so please forgive me if this sounds ignorant. But the 99/8's Extended BASIC was able to handle some of what you described. I realize that may be completely irrelevant since you aren't using Extended BASIC II as your codebase. But you can shift from 32x24 mode to 40x24 mode with CALL GRAPHICS(2) and then CALL CHAR(65,"FF18FF18FF18") works just like you would expect it in 32x24 mode.

 

It may be impossible to do this with your code base just because of the starting point of it, and I also don't know if the GPL source code of Extended BASIC II is even available to look at, but it sounds like TI was able to make whatever you are describing above work.

 

Like I said, it may be completely impossible without rewriting the whole RXB from scratch, so feel free to tell me to go away

You are correct in many ways.

99/8's Extended Basic from Ninerpedia:

There is 64KB of random access memory standard on both versions of the TI-99/8 motherboard, with the possibility of extending that to 15MB using memory cards in the Peripheral Expansion Box (PEB). 220 KB of System ROMs contains the code for the operating system, the HexBus I/O interface, TI Extended BASIC II, and the core support routines for the UCSD p-System. Most of the ROMs were actually GROMs, a specialized medium-speed memory chip developed by TI with its own 13-bit address bus. GROMs are treated as devices by the operating system. The majority of surviving machines do not have fully-functional versions of the UCSD p-System GROMs (or don't have them at all).

 

That XB2 on the TI99/4A had less then half the Program space as on the current TI99/4A XB or RXB or XB 2.7 or SuperXB.

 

It would be impossible to have backward compatibility in the F18 XB without a huge memory increase, there is no FREE EXTRA MEMORY IN THE TI99/4A.

(And 2K will not cut it to pull this off. Possibly 4K at the least.)

Edited August 10, 2018 by RXB

[matthew180]

A new firmware V1.9 is available for download from the first post in this thread (as usual):

 

http://atariage.com/forums/topic/207586-f18a-programming-info-and-resources/?do=findComment&comment=2676606

 

This biggest change in this firmware is a fix to the horizontal timing that has been there since day-1. It is amazing how many problems 6.4 pixels, or about 254ns) can cause, and how 59.4Hz refresh vs. 59.9Hz will break a good number of games! On the 99/4A this fixes Pole Position, and probably some other titles that I am not aware of. On the ColecoVision it fixes a rather large pile of titles, as well as the problems on the PAL ColecoVision consoles.

 

Note the unused sprite-linking feature was removed to ease up on the FPGA resource utilization. There is a complete change-log entry in post #1, so if you are writing software for the F18A please review the changes.

 

Also in the update ZIP file is an in-system updater for the ColecoVision (requires a Mega-Cart). Thanks to Tursi for making this happen, and for automating the tedious process of making the in-system updater programs in general.

 

I would like to encourage people to update, but as always, things can go wrong with the in-system updaters. If something happens and you end up with a non-functional F18A, I have a $1 update service on my website (basically it costs you shipping). I realize this can be expensive for people not in the U.S., but I might be able to find a few people in other countries who have a JTAG cable and who would be willing to help in cases where something goes wrong.

[jblenkle]

**F18A_V19_Coleco.rom**

Is this for the ADAM computer too? Or just ColecoVision?

 

A new firmware V1.9 is available for download from the first post in this thread (as usual):

 

http://atariage.com/forums/topic/207586-f18a-programming-info-and-resources/?do=findComment&comment=2676606

 

This biggest change in this firmware is a fix to the horizontal timing that has been there since day-1. It is amazing how many problems 6.4 pixels, or about 254ns) can cause, and how 59.4Hz refresh vs. 59.9Hz will break a good number of games! On the 99/4A this fixes Pole Position, and probably some other titles that I am not aware of. On the ColecoVision it fixes a rather large pile of titles, as well as the problems on the PAL ColecoVision consoles.

 

Note the unused sprite-linking feature was removed to ease up on the FPGA resource utilization. There is a complete change-log entry in post #1, so if you are writing software for the F18A please review the changes.

 

Also in the update ZIP file is an in-system updater for the ColecoVision (requires a Mega-Cart). Thanks to Tursi for making this happen, and for automating the tedious process of making the in-system updater programs in general.

 

I would like to encourage people to update, but as always, things can go wrong with the in-system updaters. If something happens and you end up with a non-functional F18A, I have a $1 update service on my website (basically it costs you shipping). I realize this can be expensive for people not in the U.S., but I might be able to find a few people in other countries who have a JTAG cable and who would be willing to help in cases where something goes wrong.

[matthew180]

It should work for the ADAM, but I do not have an ADAM to test with. Maybe someone in the CV sub-forum can confirm that is works or not with the ADAM. I think it *should* work, and you can see if the program at least starts up without any harm. The updater also does CRC checking and will not proceed if there are any problems reading the data. I think you are safe to try.

[jblenkle]

OK, Matthew or anyone...I just tried this on my ADAM and I am seeing this on my screen:

 

 

It's been sitting there about 15 minutes. Does this mean it did not update and it's safe to turn it off?

 

 

 

It should work for the ADAM, but I do not have an ADAM to test with. Maybe someone in the CV sub-forum can confirm that is works or not with the ADAM. I think it *should* work, and you can see if the program at least starts up without any harm. The updater also does CRC checking and will not proceed if there are any problems reading the data. I think you are safe to try.

 

[matthew180]

Yes it is safe to power-off at that point. It is waiting for the host CPU to read the data from the ROM, but apparently that is failing. It is possible that the ADAM has crashed. You can power cycle the computer and try again. The update to the F18A's flash does not happen until the data has successfully been read from the source storage device (ROM or disk) and CRC checked. After loading, the update is actually performed by the GPU itself and does not depend on the host computer. We tried really hard to make it so you can't brick the device during the update.

 

If you try again and the update still does not work, there must be something different between the ADAM and the CV or how the ADAM talk to a MegaCart. If you have a CV or 99/4A, you can put your F18A in one of those other systems to do the update (more of a pain I know). Until I can get my hands on a ADAM, or understand what it is doing differently, I can't fix the updater for the ADAM. Sorry.

[jblenkle]

Humphhh!!! Tried it again as you suggested and this time it worked perfectly. Weird!!!

 

Yes it is safe to power-off at that point. It is waiting for the host CPU to read the data from the ROM, but apparently that is failing. It is possible that the ADAM has crashed. You can power cycle the computer and try again. The update to the F18A's flash does not happen until the data has successfully been read from the source storage device (ROM or disk) and CRC checked. After loading, the update is actually performed by the GPU itself and does not depend on the host computer. We tried really hard to make it so you can't brick the device during the update.

 

If you try again and the update still does not work, there must be something different between the ADAM and the CV or how the ADAM talk to a MegaCart. If you have a CV or 99/4A, you can put your F18A in one of those other systems to do the update (more of a pain I know). Until I can get my hands on a ADAM, or understand what it is doing differently, I can't fix the updater for the ADAM. Sorry.

Edited January 4, 2019 by jblenkle

[phattyboombatty]

I just reprogrammed my F18a with the v1.9 firmware. It was a flawless update using Tursis excellent updater on my Super ColecoVision.

 

Thank you Matthew for your continued support for this awesome product!

[matthew180]

Humphhh!!! Tried it again as you suggested and this time it worked perfectly. Weird!!!

 

 

I don't find it that weird really. These old systems don't always work as expected every time, and the Coleco systems (CV and ADAM) were not actually very well made. Their PCBs are pretty cheap quality, the boards have tons of revisions, and the designs are actually what I *would* call weird. For example, building the computer's power supply into the printer!?

 

Anyway, thanks for giving it another go, I'm glad it worked. Now we know the updater works on the ADAM, and your F18A is updated. :-)

[+Schmitzi]

Hi Matthew,

 

do you have a (direct?) link to the v1.9-update ? I cannot find it.

(I used the link from post #1 and some more).

I only see this:

 

thx

 

 

[+chue]

do you have a (direct?) link to the v1.9-update ? I cannot find it.

 

 

There is a zip file in the first post of this thread. It appears to be what you are looking for.

[jblenkle]

How dare you speak ill of my favorite computer of all time <grin>...

 

 

I don't find it that weird really. These old systems don't always work as expected every time, and the Coleco systems (CV and ADAM) were not actually very well made. Their PCBs are pretty cheap quality, the boards have tons of revisions, and the designs are actually what I *would* call weird. For example, building the computer's power supply into the printer!?

 

Anyway, thanks for giving it another go, I'm glad it worked. Now we know the updater works on the ADAM, and your F18A is updated. :-)