F18A programming, info, and resources

[Omega-TI]

Hmmm, well now... mind blown by Rasmus AGAIN.

I guess I need to find the update file...

[matthew180]

The update instructions and download files are always on the first post of this thread:

 

http://atariage.com/forums/topic/207586-f18a-programming-info-and-resources/?p=2676606

[Asmusr]

If you write to a register where reg# >= 8 and reg# != 57 without unlocking, does the F18A ignore the write or write to reg# & 7? I think it's the former but just want to make sure JS99er is doing it right.

[matthew180]

It will write to whatever register is represented by the low 3-bits (>01, >02, and >04), which is what the original 9918A will do. This is the main reason I had to include the lock. Poorly written software that did not make sure bits >08, >10, and >20 were 0 would write to the upper F18A registers. This was mostly exposed by some ColecoVision games that would crash on the F18A, but I'm sure there are some 99/4A examples as well. Took me a while to find that. Ironically, those same poorly written programs will crash on a 9938/58 since those chips do not protect against registers writes over 7 in any way.

[Asmusr]

Thanks. If that's the case then I don't understand how TurboForth 1.2 in 80 column mode is working on a real F18A. If I ignore the writes it works, but if I use the lower 3 bits the screen turns blank/blue. This is an extract from the JS99er log for TurboForth:

 

...

Text 80 mode selected
Write >88 to F18A register 8 (>08) without unlocking.
Text mode selected
Write >00 to F18A register 9 (>09) without unlocking. <- will write to reg 1
Write >00 to F18A register 10 (>0A) without unlocking.
Write >00 to F18A register 11 (>0B) without unlocking.
Write >94 to F18A register 12 (>0C) without unlocking.
Write >10 to F18A register 13 (>0D) without unlocking.
Write >00 to F18A register 14 (>0E) without unlocking.

...

 

The registers end up like this:

VR0:>88 VR1:>00 VR2:>00 VR3:>00 VR4:>94 VR5:>10 VR6:>00 VR7:>F4

 

VR1:>00 means that the screen is disabled. Probably me doing something wrong, just can't figure out what it is.

[matthew180]

Wait. I just looked at the HDL for the F18A and it looks like register writes over 7 are ignored if the F18A is not unlocked. I'll have to look at this harder to make sure, because it does not seem like that would be correct. I'm sure I tested this, so now I need to also go check my notes and various conversations.

[+Lee Stewart]

The register writes to VR00 – VR14 for 80-column text mode are consistent with a V9938 with 16KiB VRAM. I know Mark (@Willsy) and Tim (@InsaneMultitasker) worked those settings out and they work just fine on real iron. I had to learn for myself that I needed all of those settings for fbForth to work in TEXT80 mode without irritating artifacts. Here are the respective settings for TurboForth and fbForth 2.0:

 

Cartridge VR00 VR01 VR02 VR03 VR04 VR05 VR06 VR07 VR08 VR09 VR10 VR11 VR12 VR13 VR14

----------- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----

TurboForth >04 >70 >03 >E8 >01 >06 >00 >F4 >88 >00 >00 >00 >94 >10 >00

fbForth 2.0 >04 >F0 >03 >E8 >01 >06 >01 >4F >88 >00 >00 >00 >4F >10 >00

 

The >04 bit (ignored by the TMS9918A) of VR00 and the >10 bit of VR01 are what set 80-column text mode. The only register beyond VR07 where we differ is VR12, which is the blinker text colors. They should be the same as VR07 to avoid trouble with the V9938 on real iron and emulation, as well. I'm not sure why VR12 for TurboForth is not >F4. (I see a possible bug in fbForth 2.0 I need to check!).

 

I do not know whether setting VR08 – VR14 has any effect on the F18A without unlocking, but the assembler must perform the writes without masking or V9938 systems, emulated and real, will not work properly. Furthermore, TurboForth and fbForth 2.0 both perform the register writes for a change to TEXT80 mode in sequence. If the register numbers are limited by a >07 mask by the assembler, the writes to VR08 – VR14 would exactly replace what was just written to VR00 – VR07 as you observed.

 

...lee

Edited August 12, 2016 by Lee Stewart

[+InsaneMultitasker]

Thanks. If that's the case then I don't understand how TurboForth 1.2 in 80 column mode is working on a real F18A. If I ignore the writes it works, but if I use the lower 3 bits the screen turns blank/blue. This is an extract from the JS99er log for TurboForth:

 

 

I usually write VR#8-14 first OR VR#14-VR#0 in descending order to ensure the 9918-specific registers VR#0-VR#7 are written last. In TIMXT I test for the F18A since the program uses features that do not exist on the V9938 side. Gazoo often cleared VR#8-VR#14 to 'be safe' and to clean up messes left behind by V9938 specific programs.

 

That said, I thought the locked F18A discarded/disregarded register writes beyond VR#7 to minimize the V9938/58 interference. Maybe that's what Matthew is seeing in post #406. Nothing else comes to my mind that seems to fit your evidence.

[Tursi]

Hmm, that surprises me too, but Classic99 supports that theory -- when the 80 column mode is enabled (in the emulator, ie: F18A), Classic99 will ignore writes to registers greater than 7 (although it checks only the last 4 bits, so 8-F are ignored, but 10-17 would still go through). I didn't comment why that's in there, either.

 

 

    if ((nReg&0x0f) > 7) {
      debug_write("Warning: writing >%02X to VDP register >%X ignored (PC=>%04X)", nData, nReg, pCPU->GetPC());
      return;
    }

[Retrospect]

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.

[RickyDean]

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.

If you buy Rich a F-18A, he might be willing to go the extra effort, for RXB.

[Asmusr]

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.

 

I started on a project like that here but there wasn't a lot of interest at the time. This was at the time the F18A had the 1.5 firmware. Later versions of the firmware support a second screen which add a lot of possibilities.

[matthew180]

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.

 

The problem is BASIC/XB use almost every bit of VRAM and expect the various VDP tables to be in specific places and be specific sizes. It is very hard to enable many of the features like extra colors because some of the VDP tables have to get bigger, which sometimes means having to move them, etc. Some of the other features could be exposed though, like scrolling. The first step would be a review of B/XB's use of VRAM and see what can change or what extra room exists, then decide what F18A features could be safely exposed and used.

 

A better alternative might be to just use the better / faster Cortex BASIC, since AFAIK it stays out of VRAM altogether.

[matthew180]

I do not know whether setting VR08 – VR14 has any effect on the F18A without unlocking, but the assembler must perform the writes without masking or V9938 systems, emulated and real, will not work properly. Furthermore, TurboForth and fbForth 2.0 both perform the register writes for a change to TEXT80 mode in sequence. If the register numbers are limited by a >07 mask by the assembler, the writes to VR08 – VR14 would exactly replace what was just written to VR00 – VR07 as you observed.

 

...lee

 

@Lee - the masking we are talking about is inside the VDP (9918A, F18A, emulator's VDP implementation), not something done by software on the host computer.

 

As for the register writing dilemma, I could not find any comments in my code or various discussions where I talked about masking vs ignoring. However, after thinking about it for a while I have concluded (and I'm writing it down now) the following:

 

The F18A was originally going for some 9938 compatibility, especially in setting 80-column mode. So all-out masking was not an option (I needed the extra bits). Just leaving VR access open was not a problem until it was found that some software would write register values over VR7, at which point I added the register locking to the F18A. The lock was implemented as "ignore VR writes over VR7 unless unlocked". While this *seemed* to fix problems with software that was previously crashing on the F18A, now I don't know if it actually introduced a subtle bug.

 

It gives me a good feeling that Classic99 also ignores writes instead of masking. Still, I should probably see what the real 9918A does.

 

At this point the F18A does not need any registers over VR7 to set 80-columns mode (the F18A does not implement the 9938 blink or extra color settings), so masking might be an option. I'm hesitant to make such a change in haste, but I have another bug fix to put out and it would be nice to have this resolved.

 

The problem is, if I mask the bits instead of ignore writes over VR7, then existing software that is currently working will break (as Rasmus found out in his emulator). But if I ignore the writes, then am I breaking some other software that runs fine on the original 9918A/28/29 ?

 

On the 99/4A it is known that most of the VR access over VR7 is to set up 80-column mode, so is it possible that the software base is small enough to be changed to work nicely with both a 9938 and 9918A, i.e. by using Tim's recommended method of writing VR0-VR7 last?

[Tursi]

 

It gives me a good feeling that Classic99 also ignores writes instead of masking. Still, I should probably see what the real 9918A does.

 

I guarantee the real VDP masks the register index to 3 bits, I have this documented as tested. Classic99 only ignores higher register writes when the "80 column hack" is enabled, which was the first F18A-ish code I put in there. Unfortunately I didn't document why I did it that way. :/

[matthew180]

Well !@#$%... If I mask the bits when the F18A is locked then that will certainly break some of the 80-column software (any software that writes VR8..VR15 after VR0..VR7). However, ignoring the VR writes over VR7 by legacy software is certainly a problem too, since on the 9918A they would be perfectly legit writes. I'm really tempted to go with masking, since the F18A is usable in many systems other than the 99/4A. I am interested in people's thoughts on this.

[+Lee Stewart]

 

@Lee - the masking we are talking about is inside the VDP (9918A, F18A, emulator's VDP implementation), not something done by software on the host computer.

 

I understand that this is part of the discussion; but, my color-highlighted response to Rasmus was to his having the assembler do the masking, something I strongly discouraged because of the 9938/58 scenario. If any user selects 80-column text mode on a machine with a 9918A with the 9918A's masking out all but the low order three bits as Mike stated it does, they deserve what they get. I will certainly look into retooling with Tim's method of writing to the VDP registers for the next build of fbForth 2.0 (I should have room), but that might not be so easy with the tight space in TurboForth, especially, if doing it backwards takes more code. I don't really know what to expect on that score.

 

...lee

[matthew180]

I understand that this is part of the discussion; but, my color-highlighted response to Rasmus was to his having the assembler do the masking, ...

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?

 

... If any user selects 80-column text mode on a machine with a 9918A with the 9918A's masking out all but the low order three bits as Mike stated it does, they deserve what they get. ...

I suppose when considering the real 9918A that can't do 80-columns, this stance would be acceptable. However the F18A can do 80-columns, and I'm trying to strike a balance.

[+InsaneMultitasker]

Well !@#$%... If I mask the bits when the F18A is locked then that will certainly break some of the 80-column software (any software that writes VR8..VR15 after VR0..VR7). However, ignoring the VR writes over VR7 by legacy software is certainly a problem too, since on the 9918A they would be perfectly legit writes. I'm really tempted to go with masking, since the F18A is usable in many systems other than the 99/4A. I am interested in people's thoughts on this.

 

Have there been any F18A 'real iron' reports of issues that stem from ignoring versus masking? You mentioned ColecoVision problems earlier. If the locked F18A -currently- ignores the writes above VR#7, have the Coleco folks been correcting programs to work within the 9918 hardware specs? Or is there some other magic at work.

 

While I don't know how many old TI 80-column programs have been modified for use with the F18A to date, the list here on AtariAge is relatively short. The barrier to converting additional programs is usually the use of the extra VRAM found in the 9938/58 systems.

 

I suspect the TI community could manage if you changed the F18A to mask the VR, provided there isn't a great host of programs that clear or set V9938/58 VRs for the heck of it.

[kbrad1]

Hi,

 

Downloaded F18AUpdate_v17 from link on page 1 of this thread but it appears to have V1.6 instead of V1.7. Checksum 40CC which matches V1.6.

 

Am i missing something?

 

Thanks!

[Asmusr]

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?

 

I suppose when considering the real 9918A that can't do 80-columns, this stance would be acceptable. However the F18A can do 80-columns, and I'm trying to strike a balance.

 

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 JS99er.

 

Initially I ignored the writes, which appears to be in line with the latest F18A firmware, but then - for some reason - I recently changed it to do the masking, and today I discovered that TurboForth was no longer running in 80 columns mode. I wish I could remember the reason, there must have been some software that didn't work. I have an idea it was of the many recent E/A#5 to cart conversions - need to check.

[Asmusr]

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.

[matthew180]

Have there been any F18A 'real iron' reports of issues that stem from ignoring versus masking? You mentioned ColecoVision problems earlier. If the locked F18A -currently- ignores the writes above VR#7, have the Coleco folks been correcting programs to work within the 9918 hardware specs? Or is there some other magic at work.

Not really any reports that I am aware of, this just came up when Rasmus asked about the F18A's behavior yesterday. It was a CV game (I don't remember which one now) that exposed the initial problem to me back in 2012 when I was doing a lot of testing. I added the VR lock and the game seemed to work. I don't think anyone in the CV community is modifying software, especially since all their software is ROM-based cartridges for the most part. For more 9918A systems, making the bits is the right answer. Any magic would be simply that ignoring the writes has not caused more problems (or the problems are going unreported).

 

I suspect the TI community could manage if you changed the F18A to mask the VR, provided there isn't a great host of programs that clear or set V9938/58 VRs for the heck of it.

 

The TI community is awesome.

 

Hi,

 

Downloaded F18AUpdate_v17 from link on page 1 of this thread but it appears to have V1.6 instead of V1.7. Checksum 40CC which matches V1.6.

 

Am i missing something?

 

Thanks!

 

I thought I corrected that. I'll check the download file. You might want to hold off though, since there will be a V1.8 firmware soon that corrects at least one bug in sprite collision detection (thanks Rasmus for finding that bug), and possibly a change to the VR writes as being discussed now.

 

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 JS99er.

 

Initially I ignored the writes, which appears to be in line with the latest F18A firmware, but then - for some reason - I recently changed it to do the masking, and today I discovered that TurboForth was no longer running in 80 columns mode. I wish I could remember the reason, there must have been some software that didn't work. I have an idea it was of the many recent E/A#5 to cart conversions - need to check.

It would be really nice to know if you did change because some software did not work with the masking, and of course what software that was. If you put JS99er back to masking, maybe I could convince Omega to test the 80-column programs to see if any have problems. That would be a nice compatibility test.

[Asmusr]

It would be really nice to know if you did change because some software did not work with the masking, and of course what software that was. If you put JS99er back to masking, maybe I could convince Omega to test the 80-column programs to see if any have problems. That would be a nice compatibility test.

 

The online version 5.4.3 is doing the making. If you choose Software/Apps/TurboForth you will see that the 80 col version is not working. Cortex Basic is working because it's unlocking the F18A.

[matthew180]

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.