F18A programming, info, and resources

[Asmusr]

I just can't remember what it was that wasn't working for me. So a question to the TI community: Is anyone aware of any software that doesn't work on the F18A but works on the old hardware [edit: old hardware means 9918A]?

[+Lee Stewart]

Ah, I see. I must have missed something in the conversation (not atypical for me), but I did not see where Rasmus suggested the masking take place in any assembler?

 

You haven't missed anything - I wasn't talking about masking taking place in any assembler but about how to correctly emulate the F18A in JS99

 

Sorry. I can be a little dense at times and this is certainly one of them. I somehow missed that you were talking about simulating/emulating the F18A and mentally jumped to “assembler” (must have had Ralph's tools on my mind!?!).

 

...lee

[+Lee Stewart]

Matthew, I can understand why you would be tempted to implement the masking in line with the 9918A, but unless we have some examples of software that don't work with the existing firmware I think you should leave it as it is. If you add the masking you know you will break TurboForth and probably many other 80 column programs. This would mean that many people would decide not to install the upcoming 1.8 firmware.

 

Possibly. But on the flip side, I don't know what software is not working with an F18A due to this. Masking is the correct thing to do for true 9918A compatibility, and I have to consider more than just the 99/4A. Firmware updates have always been a problem, since all platforms other than the 99/4A don't have an in-system update. Most F18As are probably running whatever firmware was current when the user bought their F18A. From time to time there are some reports of a program not exactly working on an F18A system (usually on the CV, and probably more that go unreported), and any time a bug is found I have to wonder if it was the problem.

 

The extant versions of fbForth 2.0 will break, as well. As I said somewhere above, I will work on implementing Tim's high-to-low VDP register writes for the next build.

 

...lee

[+OLD CS1]

Is there another jumper available on the board? This seems serious enough to me to merit a configuration option. A jumper on the board to enable masking for systems other than the TI which might be affected, or for those who might be running software on the TI which is affected should any be found. If I understand correctly, a soft switch would not be appropriate as software which would be affected would be unaware of the F18A and would be the culprits in the first place.

[matthew180]

No, all the jumpers on the F18A are used now.

 

Lee, is access to the VDP registers exposed in fbForth? If so, could a work around for older versions be to set 80 column mode, then set VR0..VR7 manually? A hack I know, but a way to have correct 9918A compatibility and still have previous fbForth programs work (albeit with the work-around).

 

What is the status of TF? Is Willsy still working on it? I thought I remember VDP register access was available from TF too?

[+OLD CS1]

No, all the jumpers on the F18A are used now.

 

How important are scan lines?

[+Lee Stewart]

... Lee, is access to the VDP registers exposed in fbForth? If so, could a work around for older versions be to set 80 column mode, then set VR0..VR7 manually? A hack I know, but a way to have correct 9918A compatibility and still have previous fbForth programs work (albeit with the work-around).

 

What is the status of TF? Is Willsy still working on it? I thought I remember VDP register access was available from TF too?

 

VDP register access is exposed with VWTR in both fbForth and TurboForth. VWTR pops a VDP register number and then a byte value from the stack:

 

HEX

04F 7 VWTR

 

will set VR07 to >4F, which in the text modes will set the foreground color to blue and the background color to white.

 

In the event this hack becomes necessary, I can write an ALC primitive to restore VR00 – VR07.

 

...lee

[matthew180]

How important are scan lines?

That's a slippery slope. Changing jumper functionality that is not backwards compatible between firmware is not something I want to do.

 

I think I have a work around, based on my opinion that the *only* 9938 features that were ever used on the 99/4A are 80-column mode and the extra VRAM (for data only), I can implement a hybrid solution. This applies to a locked F18A only. When the F18A sees 80-column mode set, it will ignore writes to VRs over 7 just like it does now. However, if 80-column mode is not set, it will mask. This works when the VRs are written forwards or backwards. This solution still has the possibility of having side effects since the 9918A ignores the M4 bit (used to select 80-column mode) in VR0, but I would speculate (or hope) that VR0's value is not abused.

Edited August 13, 2016 by matthew180

[Tursi]

I think that's a very fair compromise, Matt, certainly it's in line with the way I'd like to see thing (fix the problem without breaking anything sensible ).

 

Abuse is always possible, but I think it's fair to say at this point that the abusing software must be on the low side.

[+InsaneMultitasker]

matthew180, on 13 Aug 2016 - 1:54 PM, said:

That's a slippery slope. Changing jumper functionality that is not backwards compatible between firmware is not something I want to do.

 

I think I have a work around, based on my opinion that the *only* 9938 features that were ever used on the 99/4A are 80-column mode and the extra VRAM (for data only), I can implement a hybrid solution. This applies to a locked F18A only. When the F18A sees 80-column mode set, it will ignore writes to VRs over 7 just like it does now. However, if 80-column mode is not set, it will mask. This works when the VRs are written forwards or backwards. This solution still has the possibility of having side effects since the 9918A ignores the M4 bit (used to select 80-column mode) in VR0, but I would speculate (or hope) that VR0's value is not abused.

 

Sounds like a good way to minimize overall impact. There are some cartridges that set VR reserved bits - a problem that required modified cartridge dumps for the 9938/58 based cards and Geneve. Since no reports of cartridge failures have come to light, VR0/M4 is probably safe for your solution.

 

 

I think I have a work around, based on my opinion that the *only* 9938 features that were ever used on the 99/4A are 80-column mode and the extra VRAM (for data only),

 

There are programs in the TI and Geneve world that utilize 9938 features besides 80 column mode. Picture viewing and some window-based software come to mind. Sadly, the really neat features were not well explored or pushed to the limits.

 

There is at least one possible scenario where your proposed change might produce odd results:

 

Some programs detect 9938/58-based systems by writing a byte to VRAM in bank 0, changing VR#14 to a 16K VRAM bank other than 0, writing a different value to the same address in the 2nd bank, changing VR#14 back to bank 0, and comparing the two values. If this happens when the F18A is locked and not in 80 columns, the detection routine may see the same value during a compare (only 16K in the F18A) and will assume a 9918 is present. VR#6 will have been modified by the VR#14 write (due to the register mask in effect) so what happens next will depend on the program and its purpose. I don't know if any currently supported programs use this detection method.

[matthew180]

Thanks for the info Tim. I don't think there is any way I can cover all situations, but I hope this hybrid solution will help on both sides. Maybe some games that did not work before on the F18A will start working, and hopefully all the existing 80-column software that currently works on the F18A will continue to work.

[Tursi]

Some programs detect 9938/58-based systems by writing a byte to VRAM in bank 0, changing VR#14 to a 16K VRAM bank other than 0, writing a different value to the same address in the 2nd bank, changing VR#14 back to bank 0, and comparing the two values. If this happens when the F18A is locked and not in 80 columns, the detection routine may see the same value during a compare (only 16K in the F18A) and will assume a 9918 is present. VR#6 will have been modified by the VR#14 write (due to the register mask in effect) so what happens next will depend on the program and its purpose. I don't know if any currently supported programs use this detection method.

 

I'd argue that failing that detection is the right answer, though, since that's testing if the RAM is there, and it's not. While that might prevent a program from jumping into 80 columns, if it is useful and truly doesn't need more than the 16k of VRAM, we can patch it pretty quickly.

[atrax27407]

One of the advantages of a 9938/9958 system is the expanded VRAM. F'WEB, for example makes full use of the 192K VRAM in the 80-column mode. With anything else, excluding MESS, the best one can do is have a severely crippled application. I was all set to purchase an F18A until I discovered the 16K VRAM limitation. I decided to acquire some spare RGB monitors instead. A F38A would be nice and so would the full implementation of a v9938 in Classic99. I would even settle for an RGB to VGA converter (scaler) that actually works for a reasonable price.

[TheMole]

One of the advantages of a 9938/9958 system is the expanded VRAM. F'WEB, for example makes full use of the 192K VRAM in the 80-column mode. With anything else, excluding MESS, the best one can do is have a severely crippled application. I was all set to purchase an F18A until I discovered the 16K VRAM limitation. I decided to acquire some spare RGB monitors instead. A F38A would be nice and so would the full implementation of a v9938 in Classic99. I would even settle for an RGB to VGA converter (scaler) that actually works for a reasonable price.

 

Can we not regurgitate this discussion over and over again please? No point in bringing this up here, as it doesn't add to the discussion at all.

[matthew180]

The V1.8 firmware is available. Please see the first post of this thread for the download.

 

The update includes a sprite collision bug fix (thank you Rasmus for finding that), and the changes to the VDP register writes as discussed above.

 

Quick summary: When the F18A is locked, I added masking of the VR bits to more closely match the real 9918A, yet still recognize the M4 bit in VR0 so 9938-style 80-column mode can be set without having to unlock the F18A. If the M4 bit is set, writes to VRs over VR7 are ignored instead of masked, which allows the existing Turbo Forth (and other 80-column software) to work as-is. In light of all of this, I would ask that in the future developers adopt the reverse VR writing (VR15..VR0), as described in previous posts.

[Asmusr]

Thank you for releasing the update. I have updated js99er to reflect the changes.

 

I noticed that the the demo disk is not actually included in the zip file - only the source. We could also add another disk with the additional 4-5 demos I have made, if you want.

[matthew180]

I missed the .dsk file? Crap. I'll fix that tonight. And yes, any additional demos you (or anyone else) want to include are always welcome!

[Omega-TI]

I'm still running 1.6 I don't like text on my screen at bootup.

I'll upgrade when I finally have to.

[matthew180]

I recommend you upgrade if only for the sprite bug and VR-write-mask fixes, which may be preventing software from working correctly.

 

I'm not sure what you mean by "I don't like text on my screen at bootup". The TI Master Title Screen has text on it when you boot the computer... However, if you are referring to the version information that I added starting in V1.7, it is *not* text on the screen like the CF7/nanopeb adds to the main title screen. The version info is done as a VGA-level overlay (think like the on-screen menu your TV or computer monitor puts up) that appears in the upper left corner of the screen for 5 seconds, then goes away. It is 57x17 *VGA* pixels in size (so it is completely in the border area of the display) and only appears at power-up, i.e. you won't see it on the 99/4A if you do a soft reboot.

 

I'll post a picture tomorrow if you are still leery about it, but it is hardly something that should keep you from getting the bug fixes. Actually, I know that the new mega demo-scene program will have display problems without the V1.8 upgrade, since it was during that development that Rasmus found the most recent sprite bug.

[Asmusr]

I know there is a dip switch/jumper for max 4 sprites on a line and another for scanlines, but I don't remember what the other jumpers are for?

[matthew180]

USR3 and USR4 control the CPUCLK output to support the differences between the 9918A, 9928/29, and 9118A, 9128/29:

 

   -- User header.  Pullup in the FPGA, a jumper in place will pull to ground.
   --
   --    USR           On    Off
   -- -------------------------
   --  1 Sprite dflt|  32  | 4
   --  2 Scan lines |  No  | Yes
   --  3 CPUCLK pin | P38  | P37
   --  4 CPUCLK en  | HI-Z | CPUCLK

   -- USR3 CPUCLK pin.  Provides support for the 9128/9129 that output CPUCLK on pin37.
   -- USR3 and USR4 - CPUCLK pin and CPUCLK Enable.
   --        _________
   -- RAS  =|1   U  40|= XTAL1   9918A    9928A/29A 9118    9128/29 F18A
   -- CAS  =|2      39|= XTAL2   ======== ========= ======= ======= ====
   -- AD7  =|3      38|= ....... CPUCLK   R-Y       CPUCLK  R-Y     HI-Z / CPUCLK
   -- AD6  =|4      37|= ....... GROMCLK  GROMCLK   NC      CPUCLK  GROMCLK / CPUCLK
   -- AD5  =|5      36|= ....... COMVID   Y         COMVID  Y       NC
   -- AD4  =|6      35|= ....... EXTVDP   B-Y       EXTVDP  B-Y     NC
   --

   -- Basically:
   --             USR3 USR4
   -- TI-99/4A     on   on    -- The 99/4A does not use the CPUCLK, but this is NOT the default of the 9918A
   -- 9928/29      on   on    -- CPUCLK on pin38 disabled so it does not cram 3.5MHz into the R-Y circuit
   -- 9918A/9118   on  off    -- CPUCLK output, GROMCLK output (pin37 is not connected on the 9118)
   -- 9128/29     off   on    -- CPUCLK on pin37 disabled, CPUCLK output on pin38 enabled
   -- not used    off  off    -- CPUCLK output on both pin37 and pin38

[towmater]

I'm still running 1.6 I don't like text on my screen at bootup.

I'll upgrade when I finally have to.

 

I see F18A's splash screen on an AppleII before the F18A chip is initialized, but I see no text on a TI+F18A that wasn't already there on a 9918a.

[matthew180]

Here are a few screen shots of the version information, as well as the screen you will see if you power up the F18A without any host computer involved (or if the host is in rest, not working, or not communicating to the F18A). On the 99/4A (and most systems) you will rarely, if ever, see the 3rd image.

 

Obviously with the Apple card you will see that image until software is run that initializes the display. The original 9918A powers up with a blank screen since VDP registers default to all zero, which means the blank bit is clear, i.e. no display. I decided the F18A would deviate from the 9918A in this aspect and power up with sensible settings so you would see something to know your F18A is working.

 

As I mentioned above, no extra "text" on the screen, the version box is in the border area, and goes away after 5 seconds.

Edited August 30, 2016 by matthew180

[Asmusr]

Here are a few screen shots of the version information, as well as the screen you will see if you power up the F18A without any host computer involved (or if the host is in rest, not working, or not communicating to the F18A). On the 99/4A (and most systems) you will rarely, if ever, see the 3rd image.

 

Do you have the version image as a bitmap? I would like to add it to JS99er.net.

[matthew180]

See attached. On the real F18A the colors are (in 12-bit color):

 

'0' bits >2B2 dark green

'1' bits >FFF white

 

f18a_bitmap_v1.8.bmp