F18A - 80 Column & Enhanced Graphics Supported Programs

[Omega-TI]

Does the 9938/58 ban include you asking for software to be ported over from the... well...... 9938/58 ?

 

Now that was goooood! I got a great belly laugh out of that!

[+Lee Stewart]

 

The 80 column Infocom Interpreter does something similar; the pattern table is moved to bank 1 (0x4100) because there is not enough contiguous VRAM space left for the patterns once the name table is expanded to accomodate the 80 column display. I moved the pattern table into a portion of the disk buffer area and patched the display routine to add a needed character offset.

...

 

I did not need to move the pattern table in fbForth—it's at 800h in both 40- and 80-column text modes. See the last few posts in fbForth—TI Forth with File-based Block I/O. I only had to move the Value Stack from 3E0h to 780h (no sprites in text modes so sprite motion table is irrelevant) and the PABs area from 460h to 135Eh. There's plenty of VRAM between 135Eh and 35D7h for PABs, file record buffers, etc., with 3 simultaneously open files. The only problem is that the VDP Rollout Area at 3C0h–3DFh cannot be moved and that's right in the middle of the 80-column text mode's screen image table! I patched fbForth's Number-to-String function to save/restore this area. It does cause a flicker in the affected area that is unavoidable, however. The transcendental functions in floating-point math also use the VROA for which I have provided functions to save/restore the VROA on their own.

 

...lee

[+InsaneMultitasker]

 

I did not need to move the pattern table in fbForth—it's at 800h in both 40- and 80-column text modes. See the last few posts in fbForth—TI Forth with File-based Block I/O. I only had to move the Value Stack from 3E0h to 780h (no sprites in text modes so sprite motion table is irrelevant) and the PABs area from 460h to 135Eh. There's plenty of VRAM between 135Eh and 35D7h for PABs, file record buffers, etc., with 3 simultaneously open files. The only problem is that the VDP Rollout Area at 3C0h–3DFh cannot be moved and that's right in the middle of the 80-column text mode's screen image table! I patched fbForth's Number-to-String function to save/restore this area. It does cause a flicker in the affected area that is unavoidable, however. The transcendental functions in floating-point math also use the VROA for which I have provided functions to save/restore the VROA on their own.

 

...lee

Hi Lee, unfiortunately for me, the VDP ram between the screen and buffers is used for other 'magic' within the interpreter.

[+Lee Stewart]

...

Unfortunately, either the program uses more than one file simultaneously or I am misinterpreting file buffer usage.

...

 

I'm sure I'm not telling you anything you don't know; but, I think the default number of open files is 3. Is there a way you can patch the interpreter to reduce that? You save 518 bytes for each open file you can eliminate. I bet you'd find out soon enough whether the program requires those extra buffers or is using the space for its own "magic".

 

...lee

[Asmusr]

VR2 is the name table base address. The 9918A and F18A only use the low 4-bits, while the 9938 uses the low 7-bits to support the expanded VRAM. The F18A will ignore all but the low 4-bits, so I don't see how setting the 4 MSbits would affect anything? I'll have to get some details from Tursi. Unless the original code was expecting to place the name table in VRAM over 16K?

 

 

The original BOOT is setting VR2 to 1 in 80 color mode and 0 in 40 column mode. The patched version sets it to 0 in both modes. Apparently on the 9938/58 the two least significant bits are ignored in 80 column mode, but on the F18A they will move the name table.

[Tursi]

Me? I didn't do anything, Tursi is the one who fixed/patched it. Tursi said it was a "one-byte" patch to zero the unused bit in VDP register 2.

To those upset: Read the datasheet. Code was written contrary to documentation and failed in the way documentation predicted. Thus "bug". Don't get bent out of shape over a label.

Edited November 8, 2013 by Tursi

[marc.hull]

To those upset: Read the datasheet. Code was written contrary to documentation and failed in the way documentation predicted. Thus "bug". Don't get bent out of shape over a label.

OK perhaps I don't understand as of yet. Not arguing but don't see where your coming from...

 

The code was written for a 9938/58 and was/did work for years and years on that platform (I assume as I never really worked it hard on my Geneve.)

 

Last week/month, whatever the platform changed and the code became broken.

 

That means pretty much by definition that the F18 and 9938 do not operate in the same fashion. So your saying that causes the software to be buggy all of a sudden ? Perhaps you could elaborate.

[+InsaneMultitasker]

OK perhaps I don't understand as of yet. Not arguing but don't see where your coming from...

 

The code was written for a 9938/58 and was/did work for years and years on that platform (I assume as I never really worked it hard on my Geneve.)

 

Last week/month, whatever the platform changed and the code became broken.

 

That means pretty much by definition that the F18 and 9938 do not operate in the same fashion. So your saying that causes the software to be buggy all of a sudden ? Perhaps you could elaborate.

The situation is very similar to how a some programs originally created for use with the 9918 didn't work with the 9938, because the author ignored documentation and set (or reset) bits that should have been reserved. A good number of cartridges and games required patching before they would work with the Geneve for this very reason.

 

My perception is that things would be simpler if folks stick to the original purpose of the F18A: a 9918 drop-in replacement with a few bonus features. The 80 column feature has everyone twisting their guts arguing about the F18A and "incompatible" programs, while missing the whole point of the upgrade to begin with.

[matthew180]

That means pretty much by definition that the F18 and 9938 do not operate in the same fashion. So your saying that causes the software to be buggy all of a sudden ? Perhaps you could elaborate.

Basically the software has bugs because the designers did not follow the rules in the datasheet (although this might not be a case where that happened). For example, in the 9918A datasheet TI very specifically notes where certain bits of VDP Registers should always be set to zero. Writing to a VDP Register is one place I found bugs in original code written for the 9918A/28/29 because the programmers specified a register value over seven (111b). The datasheet specifies that when writing to a register you are supposed to pass the first byte like this:

 

0 1 2 3 4 5  6  7
------------------
1 0 0 0 0 R0 R1 R2

.

If you pass in 10001111b on a 9918A/28/29 as the register to write, you will still only write to VR7. However on the 9938/58 you will write to VR15 and cause all kinds of problems. This is because the 9938/58, as well as the F18A, needed to use those extra unused bits (1..4) to expand the VDP Registers to add functionality. So, all of a sudden software that ran fine on a 9918A would break on a 9938. The "bug" never affected the 9918A because bits 1..4 were simply not used to specify the VR to write, but they are critical on the 9938. So really it is only a bug depending on what VDP you are using, but could run fine on all the VDPs if the programmer had followed the rules.

 

It was exactly this problem that made me add a "lock out" of the VDP Registers over seven on the F18A, and finding this bug was really hard since only a few programs I tested with would expose the problem.

 

As for the problem with VR2 and the 80-column mode, Rasmus pointed out what I needed to know. It seems I created my own bug in an attempt to be a little more flexible with the name table placement in 80-column mode. Plenty of bit twiddling follows:

 

Ignoring the 9938's expanded address space (which does not matter in this case), VRAM addressing uses 14-bits (2^14) which gives you 16K of VRAM. The name table base address in VR2 specifies the MBbits of the address where the table will be located in VRAM, with the lower bits being generated by the video counters to address pattern name in the name table:

 

A13 A12 A11 A10 | A9  A8  A7  A6  A5  A4  A3 | A2  A1  A0
VR2 VR2 VR2 VR2 |        Y counter / 8       | X counter / 8

.

A9..A0 == 10-bits == 1K. That means the 4-bits from VR2 can locate the name table on a 1K boundary for the 32x24 GM1. The Y counter is divided by 8 because tiles are 8-pixels tall and therefor will address the same byte in the name table for 8 scan lines. The X counter is divided by 8 because tiles are 8-pixels wide and will therefore address the same byte in 8-pixel groups across the current scan line.

 

All this address manipulation is easy to do by simply combining certain bits from the various VDP Registers and internal counters that drive the display. It is easy because everything is conveniently divisible by 8, but that is not the case with the text modes. For the text modes there is a dedicated counter that is used to generate the address in the name table:

 

A13 A12 A11 A10 | A9  A8  A7  A6  A5  A4  A3  A2  A1  A0
VR2 VR2 VR2 VR2 |             text mode counter

.

For T40, 40x24 == 960 bytes. For every *six* horizontal pixels the text mode counter is incremented so the proper name table address is generated to get the pattern name for that location. The name table can still be located on 1K boundaries.

 

Now, in T80 mode, there is a problem: 80x24 == 1920 bytes, which is over the 1K size and requires 11-bits to address the whole name table. That means you lose one of the bits from VR2 for locating the table, and the T80 name table can only be located on 2K boundaries:

 

A13 A12 A11 | A10  A9  A8  A7  A6  A5  A4  A3  A2  A1  A0
VR2 VR2 VR2 |            text mode counter

.

But wait, there is more. On the 9938 you have the option to display 26.5 rows, and since text modes only use 6-pixels per tile they use up the name table bytes even faster, to the point where they display what would be on row 27:

 

40x27 == 1080 bytes, requires 11-bit text mode counter

80x27 == 2160 bytes, requires 12-bit text mode counter

 

So, on the 9938 T40-mode will only use 3-bits of VR2 (2K alignment), but T80 will only use 2-bits of VR2 (4K table alignment).

 

9938 T40 Name Table Addressing:

A13 A12 A11 | A10  A9  A8  A7  A6  A5  A4  A3  A2  A1  A0
VR2 VR2 VR2 |            text mode counter

9938 T80 Name Table Addressing:
A13 A12 | A11 A10  A9  A8  A7  A6  A5  A4  A3  A2  A1  A0
VR2 VR2 |               text mode counter

.

So it can be seen that the low bits of VR2 really don't matter because they are simply not used. In 9938 datasheet I have, for T80 setup it shows those bits should be "1" but it really should not matter.

 

Having said all that, this is where the F18A is having a problem. I also needed a 12-bit counter to track T80 mode, especially since I have a ROW30 mode and the T80 name table can be as large as 2400 bytes.

 

However, I didn't like limiting the name table location to 4K boundaries, and this is where I caused this problem. Instead of bit twiddling VR2 with the text mode counter, I *added* the text mode counter to the 4-bits from VR2 like this:

 

  A13 A12 A11 A10  A9  A8  A7  A6  A5  A4  A3  A2  A1  A0
  --------------------------------------------------------
  VR2 VR2 VR2 VR2 | 0   0   0   0   0   0   0   0   0   0
+  0   0 |              text mode counter
  --------------------------------------------------------
       addition result to generate name table address

.

Creating a 14-bit adder is easy to do in an FPGA, but not something a chip designer would take lightly. That's why the 9938 bit twiddled to make the address and why the 9938 T80 name table is limited to 4K boundaries.

 

But on the F18A you can still place the text mode name table on 1K boundaries even though the table itself will still be the same size (over 2K in some cases.) Now that I see the consequences of my decision, I'm not sure if it was a good idea. This could change (be fixed?) with a firmware update, but 4K boundaries just seemed too restrictive for T80 mode with the limited 16K.

Edited November 8, 2013 by matthew180

[Asmusr]

While searching for 80 old column utilities to dig up and bring out into the open for F18A users, I came across the attached 80 COLUMN VERSION of Mass Transfer.

 

Now this program comes up just fine in the emulation of the F18A under Classic99, but on the actual F18A itself, it's screwed up. This should be an easy tweak for one of you TI-Gods out there.

 

So anyone want to pick up the baton and run the final lap for the rest of the team?

 

Mass Transfer is also setting VDP reg. 2 to 1. It can be patched by setting the word at >DDB4 to >0200 (in Classic99 debugger: CDDB4=0200).

[marc.hull]

Basically the software has bugs because the designers did not follow the rules in the datasheet (although this might not be a case where that happened). For example, in the 9918A datasheet TI very specifically notes where certain bits of VDP Registers should always be set to zero. Writing to a VDP Register is one place I found bugs in original code written for the 9918A/28/29 because the programmers specified a register value over seven (111b). The datasheet specifies that when writing to a register you are supposed to pass the first byte like this:

 

0 1 2 3 4 5  6  7
------------------
1 0 0 0 0 R0 R1 R2

.

If you pass in 10001111b on a 9918A/28/29 as the register to write, you will still only write to VR7. However on the 9938/58 you will write to VR15 and cause all kinds of problems. This is because the 9938/58, as well as the F18A, needed to use those extra unused bits (1..4) to expand the VDP Registers to add functionality. So, all of a sudden software that ran fine on a 9918A would break on a 9938. The "bug" never affected the 9918A because bits 1..4 were simply not used to specify the VR to write, but they are critical on the 9938. So really it is only a bug depending on what VDP you are using, but could run fine on all the VDPs if the programmer had followed the rules.

 

It was exactly this problem that made me add a "lock out" of the VDP Registers over seven on the F18A, and finding this bug was really hard since only a few programs I tested with would expose the problem.

 

As for the problem with VR2 and the 80-column mode, Rasmus pointed out what I needed to know. It seems I created my own bug in an attempt to be a little more flexible with the name table placement in 80-column mode. Plenty of bit twiddling follows:

 

Ignoring the 9938's expanded address space (which does not matter in this case), VRAM addressing uses 14-bits (2^14) which gives you 16K of VRAM. The name table base address in VR2 specifies the MBbits of the address where the table will be located in VRAM, with the lower bits being generated by the video counters to address pattern name in the name table:

 

A13 A12 A11 A10 | A9  A8  A7  A6  A5  A4  A3 | A2  A1  A0
VR2 VR2 VR2 VR2 |        Y counter / 8       | X counter / 8

.

A9..A0 == 10-bits == 1K. That means the 4-bits from VR2 can locate the name table on a 1K boundary for the 32x24 GM1. The Y counter is divided by 8 because tiles are 8-pixels tall and therefor will address the same byte in the name table for 8 scan lines. The X counter is divided by 8 because tiles are 8-pixels wide and will therefore address the same byte in 8-pixel groups across the current scan line.

 

All this address manipulation is easy to do by simply combining certain bits from the various VDP Registers and internal counters that drive the display. It is easy because everything is conveniently divisible by 8, but that is not the case with the text modes. For the text modes there is a dedicated counter that is used to generate the address in the name table:

 

A13 A12 A11 A10 | A9  A8  A7  A6  A5  A4  A3  A2  A1  A0
VR2 VR2 VR2 VR2 |             text mode counter

.

For T40, 40x24 == 960 bytes. For every *six* horizontal pixels the text mode counter is incremented so the proper name table address is generated to get the pattern name for that location. The name table can still be located on 1K boundaries.

 

Now, in T80 mode, there is a problem: 80x24 == 1920 bytes, which is over the 1K size and requires 11-bits to address the whole name table. That means you lose one of the bits from VR2 for locating the table, and the T80 name table can only be located on 2K boundaries:

 

A13 A12 A11 | A10  A9  A8  A7  A6  A5  A4  A3  A2  A1  A0
VR2 VR2 VR2 |            text mode counter

.

But wait, there is more. On the 9938 you have the option to display 26.5 rows, and since text modes only use 6-pixels per tile they use up the name table bytes even faster, to the point where they display what would be on row 27:

 

40x27 == 1080 bytes, requires 11-bit text mode counter

80x27 == 2160 bytes, requires 12-bit text mode counter

 

So, on the 9938 T40-mode will only use 3-bits of VR2 (2K alignment), but T80 will only use 2-bits of VR2 (4K table alignment).

 

9938 T40 Name Table Addressing:

A13 A12 A11 | A10  A9  A8  A7  A6  A5  A4  A3  A2  A1  A0
VR2 VR2 VR2 |            text mode counter

9938 T80 Name Table Addressing:
A13 A12 | A11 A10  A9  A8  A7  A6  A5  A4  A3  A2  A1  A0
VR2 VR2 |               text mode counter

.

So it can be seen that the low bits of VR2 really don't matter because they are simply not used. In 9938 datasheet I have, for T80 setup it shows those bits should be "1" but it really should not matter.

 

Having said all that, this is where the F18A is having a problem. I also needed a 12-bit counter to track T80 mode, especially since I have a ROW30 mode and the T80 name table can be as large as 2400 bytes.

 

However, I didn't like limiting the name table location to 4K boundaries, and this is where I caused this problem. Instead of bit twiddling VR2 with the text mode counter, I *added* the text mode counter to the 4-bits from VR2 like this:

 

  A13 A12 A11 A10  A9  A8  A7  A6  A5  A4  A3  A2  A1  A0
  --------------------------------------------------------
  VR2 VR2 VR2 VR2 | 0   0   0   0   0   0   0   0   0   0
+  0   0 |              text mode counter
  --------------------------------------------------------
       addition result to generate name table address

.

Creating a 14-bit adder is easy to do in an FPGA, but not something a chip designer would take lightly. That's why the 9938 bit twiddled to make the address and why the 9938 T80 name table is limited to 4K boundaries.

 

But on the F18A you can still place the text mode name table on 1K boundaries even though the table itself will still be the same size (over 2K in some cases.) Now that I see the consequences of my decision, I'm not sure if it was a good idea. This could change (be fixed?) with a firmware update, but 4K boundaries just seemed too restrictive for T80 mode with the limited 16K.

 

Now that it is a done deal and people are changing software to accommodate it, my suggestion would be to leave it alone. Good explanation, Not sure I followed it all so..........

 

The long and short of it is that the F18 is slightly different than the 9938 in 80 column text mode ?

[matthew180]

Now that it is a done deal and people are changing software to accommodate it, my suggestion would be to leave it alone. Good explanation, Not sure I followed it all so..........

 

The long and short of it is that the F18 is slightly different than the 9938 in 80 column text mode ?

The mode itself is the same. You have 80-columns by 24 rows, 6x8 tiles, and two colors. It is the name table placement via VR2 that is slightly different, and only if the 9938 code sets the two LSbits of VR2 to something other than zero.

 

I could still roll out a firmware update since I don't think anyone has written F18A-specific T80 code that relies on the 1K boundary placement. I'll leave that up to community consensus.

[+OLD CS1]

This is more curiosity than desire. The 8563 used for the Commodore 128's 80 column mode is able to do 16 more-or-less ANSI colors in 16k with 8x8 characters (640x200.) My guess is the VDP's table layout might preclude similar ability? Does the 9938/58 support color in 80 columns?

[matthew180]

I don't know about the 9938 (I don't think it does), but the F18A allows full color in T40 and T80 modes, as well as sprites and the bitmap layer. You have to enable one of the Enhanced Color Modes though.

[RXB]

mathhew180 " But on the F18A you can still place the text mode name table on 1K boundaries even though the table itself will still be the same size (over 2K in some cases.) Now that I see the consequences of my decision, I'm not sure if it was a good idea. This could change (be fixed?) with a firmware update, but 4K boundaries just seemed too restrictive for T80 mode with the limited 16K. "

 

Why when we have a standard that worked for years it is always much more easy to use (even if it is slightly odd) then to start a whole new can of worms and complicate the standard into a nightmare of complications. If the F18 had the same memory configuration as the 9938/9958 all this patching would not be needed would it?

 

But that is water under the bridge and as previously stated the Drop in Replacement reason is now secondary to 80 column mode that only works in the F18.

See standards ignored or changed always lead to somewhat of a mess. I feel sorry for you in this giant headache buddy.

Edited November 8, 2013 by RXB

[RXB]

I don't know about the 9938 (I don't think it does), but the F18A allows full color in T40 and T80 modes, as well as sprites and the bitmap layer. You have to enable one of the Enhanced Color Modes though.

 

Here is the 9958 and 9938 manuals and they did have Horizontal Scroll built in. And a hardware mouse routine.

 

It also appears a 16 color text mode (sort of like half text half Bit Mapped mode) and several types of memory configurations.

 

I am not a hardware guy but Gary Bowser who made the TIM card stated that without to much trouble the TI 34000 VDP chip could be used.

 

If you ever seen that chip work it was GOD like with a insane amount of memory even by today's standards still impressive.

 

It was mostly used by CAD/CAM people and NASA for video simulations.

yamaha_V9958.pdf

[RXB]

Oh and here is the other manual:

 

 

[RXB]

Oh and here is the 9938

[RXB]

Ok well will not take the file attachment ?

[+acadiel]

OK, I might have gotten this lost in another thread..

 

Telco has a 40/80 column toggle. Can we make this work properly with the F18A?

 

Thanks!

 

 

[matthew180]

Why when we have a standard that worked for years it is always much more easy to use (even if it is slightly odd) then to start a whole new can of worms and complicate the standard into a nightmare of complications. If the F18 had the same memory configuration as the 9938/9958 all this patching would not be needed would it?

The F18A is not a 9938/58 replacement. And in this case it has nothing to do with the memory configuration. There is no "standard" for setting VR2 in the VDP. I also did follow the 9938 datasheet, however as I explained above I made a decision to add the bits versus truncate. Had I known there was code setting those LSbits, I probably would have truncated vs. add the bits, and this would not be causing any problem.

[Omega-TI]

OK, I might have gotten this lost in another thread..

 

Telco has a 40/80 column toggle. Can we make this work properly with the F18A?

 

Thanks!

 

 

 

I second the nomination!

[Omega-TI]

 

Here is the 9958 and 9938 manuals and they did have Horizontal Scroll built in. And a hardware mouse routine.

 

It also appears a 16 color text mode (sort of like half text half Bit Mapped mode) and several types of memory configurations.

 

I am not a hardware guy but Gary Bowser who made the TIM card stated that without to much trouble the TI 34000 VDP chip could be used.

 

If you ever seen that chip work it was GOD like with a insane amount of memory even by today's standards still impressive.

 

It was mostly used by CAD/CAM people and NASA for video simulations.

 

 

The perfect place for this discussion is: << HERE >>

[Omega-TI]

By now you all know that 4A/DOS will:

 

1) Will do 80 Columns on the F18A

2) Works with the V2 Nano-PEB's COM1

 

But did you know it also works great with a regular TI Peripheral Expansion Box that has an HDX equipped RS-232?

 

Sorry for the poor image quality, it was taken with my cellphone.

 

Also if you want to have it automatically default to HDX1 on BOOTUP, you'll have to use a sector editor to replace all occurrences of "DSK1." with "HDX1." (remember it searches for CHARA1 on BOOTUP).

[Asmusr]

The F18A is not a 9938/58 replacement. And in this case it has nothing to do with the memory configuration. There is no "standard" for setting VR2 in the VDP. I also did follow the 9938 datasheet, however as I explained above I made a decision to add the bits versus truncate. Had I known there was code setting those LSbits, I probably would have truncated vs. add the bits, and this would not be causing any problem.

 

I don't think you should change anything because: 1. The flexibility of placing the name table on 1K boundaries is a good feature. 2. The software that sets those bits can easily be patched. 3. It is not desirable to have several functionally different firmware versions.