F18A MK2

[+9640News]

The TI and Geneve is but a fraction of the people interested in this device.

 

Minimally, I think the priority for design compatability should be in this order:

 

1. 9918

2. F18A

3. 9938

4. MK2

 

If the device is marketed with any reference to the 9938, then by all rights, it should support all the features of the 9938. If it has more features (MK2) than the 9938, then super!!!

 

If the 9938 can not be fully implemented, then MK2 should move up to slot 3 and all references to the 9938 should be disregarded.

 

When you open up 9938 capability, then one has really expanded the opportunity for utilization beyond custom written programs for it. How many do we have now for the TI with F18A capabiltity? Not many. However, for the 9938, there are lots of programs that can tap into it right now and if we had MK2, then all the better for those that want to custom write programs for it.

 

My 2 cents.

 

Beery

 

 

 

 

[+InsaneMultitasker]

I'm not totally sure what will be the extent of the 9938 support yet, I've been so busy with the video output problem I have not had much time to think about it. I was just looking through the 9938 docs again and see that VR14 contains the extra bits for the address, and the "extra page" is selected by yet another bit in some other register. Strange setup. Does rolling over the original 14-bit address pointer cause the "page bits" in VR14 to increment?

Personal opinion: v9938 text mode and addressing compatibility would be prudent and useful for the TI/Geneve world. the other modes have not been used for much and in my opinion would be a waste of time to implement up front. Leverage the F18A graphics modes with 9938 text mode compatibility for legacy software and build from there.

 

There is some rollover but if I remember correctly, it only occurs in certain v9938 modes. this was a major issue at one time with disk controllers, since the TI and Corcomp (any perhaps others) would write to the last byte in memory and flip the page.

[Opry99er]

Am I remembering correctly that 80 col Funnelweb utilizes all the available 192K of VRAM?

[+Lee Stewart]

Am I remembering correctly that 80 col Funnelweb utilizes all the available 192K of VRAM?

 

Yup

 

...lee

[Tighe]

* Standard 20-pin FPC header but make my own connector board with a DVI header. This would allow an audio header on the header board and possibly analog VGA signals.

 

This seems like the best choice, some applications would prefer a analog signal and others a digital signal. It's easy enough to buy a DVI to HDMI adapter.

[JB]

Yeah, I rather like having DVI-I as an output.

DVI-D isn't terrible either, though I admit that "maybe VGA" made my eyes light up.

[Omega-TI]

Personal opinion: v9938 text mode and addressing compatibility would be prudent and useful for the TI/Geneve world. the other modes have not been used for much and in my opinion would be a waste of time to implement up front. Leverage the F18A graphics modes with 9938 text mode compatibility for legacy software and build from there.

 

I tend to agree. Currently the F18A can use many, but not all of the older 80 column text based programs, so a MK2 with extra memory being 9938 compliant would satisfy most people. If worse came to worse, for compliance, a firmware upgrade could be made available to older F18A users, but that would probably not be necessary.

 

Sometimes in our hobby world, reality comes out to play, and it's not possible to please everyone 100% of the time, so shooting for that 90% may be all that is possible or practical. Being cognizant of the likely path a choice will lead us, if the result is having to code for multiple platforms, the result would obviously be a reduced user base for each new program, so less of an incentive for a programmer to write new stuff.

 

In using the best of both worlds and merging them, there would be less work for Matthew, less work for future software developers (programming hobbyists), less contention within the community and a greater audience of users for new software. (IMHO)

[Omega-TI]

Yeah, I rather like having DVI-I as an output.

... I admit that "maybe VGA" made my eyes light up.

 

Almost everyone has a VGA monitor to spare for their TI. If they are not already using VGA, they're dirt cheap to come by. DVI compliant monitors are not as prevalent and might force the additional expense of a new monitor on top of obtaining a MK2, which might inhibit sales.

 

It'll be interesting to see how this all plays out.

[Pheonix]

Why not, for backwards compatibility, leave the addressing & extra information where it is (at 0x4000,) by default, but add in (maybe at 0xFFFF,) a register that can move that, so that you can create a single large continuous RAM block? You could use the same address, to define paging method as well. Software written for the MK1 would not be accessing that address, so the default would stay, and it would act as the software expects. But new software could change that, and thus get greater access to the increased RAM of the MK2. It would be nice, though not required, if whatever block is defined as the control block, could be non-paging or auto mirroring (if you decide to go with just having 8 pages of 64k each.) Would avoid the trouble of having the register that defines the page change when you shift pages. Could result in a page switching loop that could be near impossible to break.

[Asmusr]

I'm not totally sure what will be the extent of the 9938 support yet, I've been so busy with the video output problem I have not had much time to think about it. I was just looking through the 9938 docs again and see that VR14 contains the extra bits for the address, and the "extra page" is selected by yet another bit in some other register. Strange setup. Does rolling over the original 14-bit address pointer cause the "page bits" in VR14 to increment?

 

According to section 1.5 on page 7 it does, but only in some modes.

V9938 MSX Video Technical Data Book.pdf

Edited December 1, 2018 by Asmusr

[Asmusr]

The GPU will also need a way to access all this memory. A 32-bit mode perhaps?

[Asmusr]

I guess there are actually 3 different types of paging to consider: 1. The page accessed via the CPU-VDP interface. 2. The page accessed by the GPU. 3. The currently displayed page or pages. Each table (pattern table, name table, sprite table, bitmap table, etc.) may be mapped to a different page or pages.

 

Double buffering, by changing the page of the currently displayed bitmap, is important for some of the games I have in mind.

Edited December 1, 2018 by Asmusr

[JB]

 

Almost everyone has a VGA monitor to spare for their TI. If they are not already using VGA, they're dirt cheap to come by. DVI compliant monitors are not as prevalent and might force the additional expense of a new monitor on top of obtaining a MK2, which might inhibit sales.

 

It'll be interesting to see how this all plays out.

DVI-I carries VGA and (basically) HDMI signals. It is a five-dollar adapter to connect it to either.

 

It seems like the optimum configuration, as it gets an end-run around the HDMI licensing mess AND preserves VGA output possibility. Only thing missing is sound.

[+mizapf]

Personal opinion: v9938 text mode and addressing compatibility would be prudent and useful for the TI/Geneve world. the other modes have not been used for much and in my opinion would be a waste of time to implement up front.

 

And graphics modes 6 and 7? There are quite some programs using it (and not just my own ones).

[+InsaneMultitasker]

 

And graphics modes 6 and 7? There are quite some programs using it (and not just my own ones).

 

I can think of 20 or so TI or Geneve programs, including graphics editors YAPP and Myart, Geneve window-driver software like CFORM, a handful of GIF/Myart viewers, a few games, fractals, and a few of my own programs. Is there really that much more out there that was written - and used - that made use of the 9938's graphics modes?

 

If Matthew's device is eventually fully compatible with the 9938 that would be an awesome feat. I still think compatibility with v9938- 80 columns and vram addressing would provide the most initial bang for the buck in the ti/geneve world for an update to the F18A.

[+9640News]

As I thought about it more, is the 9918 pin compatible with the 9938? If not, then the MK2 would never work on a Geneve. However, any 9938 programs written for the TI side of the things on the Geneve would work if the coding was 9938 compatible.

 

Beery

[Omega-TI]

 

I can think of 20 or so TI or Geneve programs...

 

That begs the question, how many of those Geneve programs can even run on a TI? Would they ever be able to run without extensive modification? If so, whose going to bother? For all the talk of making the MK2 a 9938 clone, I have to wonder what the point is. Geneve users, as far as I know can't use it, and the TI has severe memory limitations in comparison to the Geneve for which these few programs were written.

[Tursi]

One of the points is MSX2, which is a bit wider a market than the Geneve or TIM... but it really comes down to what Matt wants to do. Adding all the 9938 features is a huge undertaking, and even the "simple" 9918A had a lot of unexpected requirements.

[Opry99er]

As I thought about it more, is the 9918 pin compatible with the 9938? If not, then the MK2 would never work on a Geneve. However, any 9938 programs written for the TI side of the things on the Geneve would work if the coding was 9938 compatible.

 

Beery

It is not pin compatible.

[+9640News]

 

That begs the question, how many of those Geneve programs can even run on a TI? Would they ever be able to run without extensive modification? If so, whose going to bother? For all the talk of making the MK2 a 9938 clone, I have to wonder what the point is. Geneve users, as far as I know can't use it, and the TI has severe memory limitations in comparison to the Geneve for which these few programs were written.

 

One has to keep in mind there were programs written on the Geneve that are either MDOS mode (not going to run on a TI-99/4A) or programs written for the GPL (TI-99/4A with 9938 capability). Programs such as Telco, Mass Transfer 80 columns, Funnelweb 80 columns and others use text mode. Others like YAPP and I believe others use various graphics mode such as what was suggested earlier up in the thread. These programs do not need to be 9938 pin compatible, only register/memory compatible to use the text and graphic modes.

 

Again, it is all up to Matt.

 

Beery

[RXB]

I think Berry is spot on for the future of F18 or MK2

[+mizapf]

I admit I may have got it wrong ... we're not talking about a v9938 replacement for the Geneve?

[matthew180]

I admit I may have got it wrong ... we're not talking about a v9938 replacement for the Geneve?

 

No, the MK2 is not being designed to specifically replace a 9938. That said, with its enhance hardware I will certainly try to make it compatible where possible (as I did with the F18A, borrowing things like T80 mode and such). Backwards compatibility with the 9918A and F18A are primary goals, with 9938 capabilities being next.

 

However, the MK2 is still in a 9918A pin-compatible package, so it will never be a 1:1 drop-in replacement for a 9938 without an adapter board (which I do plan to make since I have a personal need for such a thing.)

 

I can tell you for sure though, that I do not plan to implement certain 9938 features like the genlock capability and such. Anything dealing with the original video signals (NTSC / PAL input and output) I'm not going to implement. If someone wants to use the MK2 as a starting point and implement all those analog features, the MK2's hardware and packaging will certainly allow them to do that.

 

I also don't like video "modes", since changing the resolution is a big PITA. It just complicates things since I have to generate a consistent, modern, digital video output. Blah.

[matthew180]

According to section 1.5 on page 7 it does, but only in some modes.

 

Bah, why does it have to be only in *some* modes? That just makes it easier to have bugs in both software and the hardware.

 

The GPU will also need a way to access all this memory. A 32-bit mode perhaps?

 

Hmm, not sure. Probably not a 32-bit mode since there is no precedence for that in the 9900 family.

 

I guess there are actually 3 different types of paging to consider: 1. The page accessed via the CPU-VDP interface. 2. The page accessed by the GPU. 3. The currently displayed page or pages. Each table (pattern table, name table, sprite table, bitmap table, etc.) may be mapped to a different page or pages.

 

Double buffering, by changing the page of the currently displayed bitmap, is important for some of the games I have in mind.

 

In looking at the 9938 datasheet a little, it seems the extra memory was addressed via an extra register (VR14) that the programmer had to manage. In that case it seems to make sense to use the same VR14 (currently purposely unused in the F18A) to do exactly the same thing in the MK2. The GPU would have to manage VR14 the same way the host-computer software has to manage VR14. In this case it does implement the idea of paging the 512K via the original 16K address space. This would also mean that the F18A's GPU can retain its current address space above 16K. The GPU will need its own paging register though, so it can access memory without interfering with the host CPU. The DMA will need to be expanded too.

 

The 9938 expanded each table's base address, so yes, each table has its own "page" reference and can reside anywhere in the expanded memory. The only problem is that I knowingly stepped into the VR8 .. VR14 area with Tile Layer 2. I was trying to say out of those registers in case I ever was to do 9938 compatibility, and look, here I am... In the 9938 VR10 and VR11 expand the base addresses for the TL1 color table and TL1 sprite attribute table. I'm not sure how to reconcile this yet, since I don't want to break any new F18A software that uses TL2.

 

Then there is also the problem that the 9938 only expanded access to 128K and the MK2 has 512K. For general VRAM reading/writing I can add the extra two bits to VR14, but for table base address placement it might be a problem for some tables.

 

Absolutely, double-buffering will be possible. I'm also kicking around ideas on how to avoid having to clear the offline buffer (although the DMA does it about as fast as possible).

 

 

Why not, for backwards compatibility, leave the addressing & extra information where it is (at 0x4000,) by default, but add in (maybe at 0xFFFF,) a register that can move that, so that you can create a single large continuous RAM block? You could use the same address, to define paging method as well. Software written for the MK1 would not be accessing that address, so the default would stay, and it would act as the software expects. But new software could change that, and thus get greater access to the increased RAM of the MK2. It would be nice, though not required, if whatever block is defined as the control block, could be non-paging or auto mirroring (if you decide to go with just having 8 pages of 64k each.) Would avoid the trouble of having the register that defines the page change when you shift pages. Could result in a page switching loop that could be near impossible to break.

 

With VR14 specifying the address bits above 16K, the memory is already paged through a register so it will not be a problem. It would be convenient for the GPU to be able to access the VRAM in 64K chunks (i.e. using the full 16-bit address of the 9900), but keeping the memory access as-is presents the least problem all around.

[+Ksarul]

Note that the V9990 expanded the memory space to 512K, but it broke a lot of other things, as it made no real effort to be fully backward-compatible with the rest of the family.