F18A MK2

[matthew180]

The USB header is on the MK2 board itself, *not* the video headers.

 

 

Note the micro-USB connector on the end of the MK2 board.  The "user options" were added on the original MK1 board as a low-profile jumper-header:

 

 

See the lower-left corner.

 

Two of the jumpers are "nice to have" settings for choosing the default number of sprites on a line(4 or 32) and the virtual scan-lines option.  The other two were for setting the GROMCLK vs CPUCLK output pins, since those are the only differences between the 9918A VDP family, other than the composite vs component output (which is moot with the F18A).  Those jumpers were needed depending on the original VDP you are replacing.

 

Either way, you had to open your computer to change the jumpers (unless you wired and mounted external switches to the header).  For the MK2, if you leave a USB cable attached all the time and run it out of your retro-computer, you will be able to change the settings whenever you want.  Ideally you would strain-relief that USB cable, or better get an internal micro-USB to panel-mount female type-B USB socket that you mount in your retro-computer case somewhere.  But that will be totally up to you.

 

Alternatively, the flash memory is completely accessible to the GPU inside the F18A, so you can write software on whatever retro-computer you want to access and change those settings.  Much like the 99/4A and CV in-system updater.  However, I cannot possibly write that retro-software for every computer that might use the F18A, so the USB interface on the MK2 is a universal way for me to offer the capability.

 

 

 

[Pheonix]

OK.  Looks like the only thing I would need/want to change is the sprite limit.  Assuming allowing 32 sprites on a line would actually break anything, that is.  So, the only thing left is flashing the firmware.  Will the MK2 be able to flash itself while running?  If so, then all that would be needed is the software to set it up & tell it to do so.  Making the USB port handy (especially while there is no software available for a particular machine,) but not absolutely essential.  Same thing with the scan-lines (I never enable those or use CRT filters, just my personal taste,) and sprites (unless it breaks something, just setting to 32 wouldn't bother me, personally.)

[Ikrananka]

12 hours ago, matthew180 said:

Two of the jumpers are "nice to have" settings for choosing the default number of sprites on a line(4 or 32) and the virtual scan-lines option.  The other two were for setting the GROMCLK vs CPUCLK output pins, since those are the only differences between the 9918A VDP family, other than the composite vs component output (which is moot with the F18A).  Those jumpers were needed depending on the original VDP you are replacing.

 

Either way, you had to open your computer to change the jumpers (unless you wired and mounted external switches to the header).  For the MK2, if you leave a USB cable attached all the time and run it out of your retro-computer, you will be able to change the settings whenever you want.  Ideally you would strain-relief that USB cable, or better get an internal micro-USB to panel-mount female type-B USB socket that you mount in your retro-computer case somewhere.  But that will be totally up to you.

 

Alternatively, the flash memory is completely accessible to the GPU inside the F18A, so you can write software on whatever retro-computer you want to access and change those settings.  Much like the 99/4A and CV in-system updater.  However, I cannot possibly write that retro-software for every computer that might use the F18A, so the USB interface on the MK2 is a universal way for me to offer the capability.

Personally, I wouldn't describe the sprites on a line (4 or 32) jumper as a "nice to have", at least not for the ColecoVision.  On the ColecoVision there a few games (including some new homebrews) that use the 4 sprites per line limit to mask parts of sprites so that they disappear behind other graphics, e.g. Penta the penguin in Antarctic Adventure.  With my MK1 F18A I installed a small switch on the back of my CV to easily switch between 4 and 32 sprites.  I must admit that having to programatically change this settings via a USB connection or a cart to flash the F18A will be a significant pain.  Is there no way to include a jumper somewhere on the MK2 for this setting?

 

 

[matthew180]

16 hours ago, Pheonix said:

Will the MK2 be able to flash itself while running?

Not sure what you mean by "running"?  When the USB cable is plugged in, two things will happen: 1. the MK2 will change to being powered by the USB connection, so it can be updated even if the system it is installed into is off.  And 2. it will reload the bit-stream to a "loader" specific configuration that will talk to the software running on the USB connected computer.  Once you update the firmware and disconnect the USB, the MK2 will reload with the normal VDP bit-stream.

 

4 hours ago, Ikrananka said:

On the ColecoVision there a few games (including some new homebrews) that use the 4 sprites per line limit to mask parts of sprites so that they disappear behind other graphics, e.g. Penta the penguin in Antarctic Adventure.

Yes, that is true and I am aware of that problem.  It is a problem without a single solution.  Some software uses the 4-sprite limit, as you mentioned, yet most software benefits from not having a sprite limit, i.e. is solves the flickering problem.  In V1.8 or V1.9 of the firmware, I introduced a change to try and at least strike a balance.  When the F18A is locked (the default unless F18A-specific software is running), then the F18A acts like it has a 4-sprite limit, i.e. collisions and functionality still work as expected for the 4-sprite limit, yet can still display all 32-sprites (if set via the jumper).

 

4 hours ago, Ikrananka said:

Is there no way to include a jumper somewhere on the MK2 for this setting?

 

Yes, there is a way, and since you are bringing it up as a potential problem, I will make a change in the MK2 for two of the inputs (the MK2 has 14 I/O available) to be used as hardware inputs for selecting a sprite-limit and scan-lines.  I don't think very many people are wiring switches to the F18A, but if you are someone who can do that, it will be an option.

 

I'm thinking it will work like this: the inputs will have pull-ups to 3.3V, and a switch can be wired to ground, which when closed will pull the input low.  When the input is high (switch is open), the sprite limit and scan-lines will be taken from the "soft" setting, i.e. the options set by the USB software interface.  When the a switch is closed and pulls the input low, the sprite limit will be set to 4, or the scan-lines will be enabled, depending on which switch is closed.  Hopefully that will be acceptable.

 

[Pheonix]

6 minutes ago, matthew180 said:

Not sure what you mean by "running"?  When the USB cable is plugged in, two things will happen: 1. the MK2 will change to being powered by the USB connection, so it can be updated even if the system it is installed into is off.  And 2. it will reload the bit-stream to a "loader" specific configuration that will talk to the software running on the USB connected computer.  Once you update the firmware and disconnect the USB, the MK2 will reload with the normal VDP bit-stream.

By "running" I meant powered up by, and providing GPU functionality to to host system.  Basically, if the correct software was written for the host system, will it be possible to flash the firmware without using the USB?  Either as a flash in place, or flash on next power up?

[matthew180]

8 minutes ago, Pheonix said:

Basically, if the correct software was written for the host system, will it be possible to flash the firmware without using the USB?  Either as a flash in place, or flash on next power up?

Yes, that is exactly how the two in-systems update programs for the MK1 work.  With a lot of help from Rasmus and Tursi, there is an in-system update program for the 99/4A and CV.  The problem with this approach is having to write custom code for each computer that can use the 9918A VDP, which is unrealistic, and getting the large (200K to 500K, depending) bit-stream file onto a medium that can be read by the retro-system.  For the CV this is not *too* bad, but it does require the user to have a flash-based MegaCart of some sort.  For the 99/4A it requires something like the CF7/nanoPEB or TiPi, etc.

[Pheonix]

With the 99/4A, would it work with a 720K floppy drive?

 

It has been my understanding, that a lot of developers (of software as well as hardware,) in the past have outsourced system specific conversion/driver production to 3rd party developers.  If a system that supports the 9918A has enough users, there is bound to be someone willing & able to write update/control software.  I'm assuming that interface control information will be available.  I imagine, probably, as a PDF, HTML, and/or text file somewhere.  

[matthew180]

50 minutes ago, Pheonix said:

With the 99/4A, would it work with a 720K floppy drive?

Should be good with that.  The MK2 bitstream is 340,952 bytes, and you might need two of them if the loader itself is being updated.

 

53 minutes ago, Pheonix said:

It has been my understanding, that a lot of developers (of software as well as hardware,) in the past have outsourced system specific conversion/driver production to 3rd party developers.

Uhm, I think you are confusing this hobby project with a commercial business that has resources.  If you have the time and money, then by all means please pay 3rd party developers to write F18A update programs for all computers that used the 9918A VDP family, and make them available as open source.

 

58 minutes ago, Pheonix said:

I imagine, probably, as a PDF, HTML, and/or text file somewhere.

The information to write an updater, i.e. write to the flash from the GPU, has been available since the F18A was released.  The source code for both the 99/4A and CV update programs is available.

 

[Pheonix]

Actually, many developers actually "charged" 3rd party producers (licensing fee,) instead of paying them

 

I was just using it as a reference, though.

[jstimson]

So, completely out-of-left-field question, and given that it sits solely in the video chip socket I suspect the answer is no, but......

 

For things like switching the sprite limitation, could there be a way to do that via a keyboard combo?  Or running a small utility on the TI that could do it when you want to switch?  In other words, any way of pushing a change to a setting via the console that would not require adding a physical switch or hooking up to USB?

 

[matthew180]

Yes, that can be done.  The sprite limit is completely programmable.  The only thing the MK1 user-jumpers do it set the power-on / reset default, but that can be over-ridden by software.  Also, the F18A registers are not affected by CPU soft resets (FCTN= on the 99/4A), but they will be reset if the actual reset-pin to the VDP is pulled low.  So, changing a cartridge will probably reset the VDP settings, and of course a power-off/on cycle.

 

You can also change the palette registers on the F18A, and those registers *do* survive a powered reset, i.e. they are only restored for power-off/on cycle.  But, to do a software selection of sprites-per-line, you would have to be able to run your settings program, then start the game or other software in question without hardware-resetting the computer.  Basically I think you need assembly language access from ROM-BASIC, which has been shown to be possible (I think the forum thread is called "breaking out of the BASIC sandbox", or something similar).

[+retroclouds]

10 hours ago, matthew180 said:

Yes, that can be done.  The sprite limit is completely programmable.  The only thing the MK1 user-jumpers do it set the power-on / reset default, but that can be over-ridden by software.  Also, the F18A registers are not affected by CPU soft resets (FCTN= on the 99/4A), but they will be reset if the actual reset-pin to the VDP is pulled low.  So, changing a cartridge will probably reset the VDP settings, and of course a power-off/on cycle.

 

You can also change the palette registers on the F18A, and those registers *do* survive a powered reset, i.e. they are only restored for power-off/on cycle.  But, to do a software selection of sprites-per-line, you would have to be able to run your settings program, then start the game or other software in question without hardware-resetting the computer.  Basically I think you need assembly language access from ROM-BASIC, which has been shown to be possible (I think the forum thread is called "breaking out of the BASIC sandbox", or something similar).

Here’s the link to that thread: 

 

[Ikrananka]

On 5/15/2020 at 3:44 PM, matthew180 said:

Yes, that is true and I am aware of that problem.  It is a problem without a single solution.  Some software uses the 4-sprite limit, as you mentioned, yet most software benefits from not having a sprite limit, i.e. is solves the flickering problem.  In V1.8 or V1.9 of the firmware, I introduced a change to try and at least strike a balance.  When the F18A is locked (the default unless F18A-specific software is running), then the F18A acts like it has a 4-sprite limit, i.e. collisions and functionality still work as expected for the 4-sprite limit, yet can still display all 32-sprites (if set via the jumper).

 

Hmm, I haven't noticed that behaviour with the V1.9 firmware.  For example, in Antarctic Adventure, with USR1 set to 32 sprites, the sprite masking does not work so when Penta falls into a crevasse his body is still completely visible.

 

On 5/15/2020 at 3:44 PM, matthew180 said:

Yes, there is a way, and since you are bringing it up as a potential problem, I will make a change in the MK2 for two of the inputs (the MK2 has 14 I/O available) to be used as hardware inputs for selecting a sprite-limit and scan-lines.  I don't think very many people are wiring switches to the F18A, but if you are someone who can do that, it will be an option.

 

I'm thinking it will work like this: the inputs will have pull-ups to 3.3V, and a switch can be wired to ground, which when closed will pull the input low.  When the input is high (switch is open), the sprite limit and scan-lines will be taken from the "soft" setting, i.e. the options set by the USB software interface.  When the a switch is closed and pulls the input low, the sprite limit will be set to 4, or the scan-lines will be enabled, depending on which switch is closed.  Hopefully that will be acceptable.

Thank you so much for making this change ???  I for one will be adding a switch for the sprite limits and it sounds like what you propose should work great.

Edited May 17, 2020 by Ikrananka

[matthew180]

2 minutes ago, Ikrananka said:

Hmm, I haven't noticed that behaviour with the V1.9 firmware.  For example, in Antarctic Adventure, with USR1 set to 32 sprites, the sprite masking does not work so when Penta falls into a crevasse his body is still completely visible.

Yes, but the sprites still *act* as if there are only 4 on a line, aside from the visibility, i.e. the collision detection still works as it would with the 4-sprite limit.  Initially the number of sprites on a line also determined which sprites were involved in collisions, which had the side effect that games relying on the 4-per line limit would incorrectly detect collisions, which broke the games.  The hybrid solution separates the visible sprites from the collision detection, which at least allows games to continue to work.

 

The collision detection is defaulted to the first 4 visible sprites, as would be the case with the original VDP, regardless of the 4/32 sprites jumper setting (which is for visibility only).  The only way to change the collision limit is to unlock the F18A and update the correct VDP register, which only software written specifically for the F18A can/will do.

[Ikrananka]

2 minutes ago, matthew180 said:

Yes, but the sprites still *act* as if there are only 4 on a line, aside from the visibility, i.e. the collision detection still works as it would with the 4-sprite limit.  Initially the number of sprites on a line also determined which sprites were involved in collisions, which had the side effect that games relying on the 4-per line limit would incorrectly detect collisions, which broke the games.  The hybrid solution separates the visible sprites from the collision detection, which at least allows games to continue to work.

 

The collision detection is defaulted to the first 4 visible sprites, as would be the case with the original VDP, regardless of the 4/32 sprites jumper setting (which is for visibility only).  The only way to change the collision limit is to unlock the F18A and update the correct VDP register, which only software written specifically for the F18A can/will do.

Ah - understood.  Thanks for clarifying,

[+9640News]

OK, got a question I need  just a bit of clarification.  Did the F18A or the MK2 versions have 80 column mode text ability like the 9938?  Something I recently saw suggested this may not be the case.  I know there is a special mode because there is an 80 column Telnet client Matt wrote, however I know that is different.  Just wasn't sure if the F18A or MK2 would allow the use of the 80 column version of Funnelweb.

Beery 

[+arcadeshopper]

OK, got a question I need  just a bit of clarification.  Did the F18A or the MK2 versions have 80 column mode text ability like the 9938?  Something I recently saw suggested this may not be the case.  I know there is a special mode because there is an 80 column Telnet client Matt wrote, however I know that is different.  Just wasn't sure if the F18A or MK2 would allow the use of the 80 column version of Funnelweb.

Beery 

It's like the 9938 t80 mode in some ways but it only has 16k ram to work with unlike the 9938 and I know funl uses that extra ram so it doesn't work.



Sent from my LM-G820 using Tapatalk

[+9640News]

1 hour ago, arcadeshopper said:

It's like the 9938 t80 mode in some ways but it only has 16k ram to work with unlike the 9938 and I know funl uses that extra ram so it doesn't work.

Sent from my LM-G820 using Tapatalk
 

 

OK, so for some 80 column programs, it will work if they are "basic".

 

Beery

 

[+Lee Stewart]

19 minutes ago, BeeryMiller said:

OK, so for some 80 column programs, it will work if they are "basic".

       Beery

 

Yes...if the extra VDP registers are set up properly. TEXT80 mode in fbForth does this automatically. Of course, you should not use that mode if you do not have an F18A or 9938/58 because the setup code does not verify that one of those VDPs is actually present.

 

...lee

[matthew180]

There is a thread around here on A.A. dedicated to 99/4A programs that work with T80, or that have been patched to work with T80.

 

The F18A allows a 9938-compatible T80 to be enabled even when the F18A is locked.  The only difference in behavior with the base F18A T80 and the 9938 is that the F18A does not (intentionally) support the blink capability.  And, as arcadeshopper mentioned, the F18A MK1 only has the original 16K of VRAM, so software that expects 128K or 192K will not work.  IMO is was the wrong choice to use VRAM instead of system RAM for software data storage; the programs would have been much more useful if they had required a system with a memory expansion like the SAMS.

 

When the F18A is unlocked, there are a lot of other options for the text modes, i.e. individual fg/bg color per-tile location, sprites are available, the bitmap layer can be enabled, etc.

[+InsaneMultitasker]

32 minutes ago, matthew180 said:

.  IMO is was the wrong choice to use VRAM instead of system RAM for software data storage; the programs would have been much more useful if they had required a system with a memory expansion like the SAMS.

 

I think this might have been more likely had the SAMS been more prevalent and available when many of the 80-column programs were written.  Even still, as a user of the extra VRAM, it would not have made sense to me to dismiss what amounts to 3-5 times the available system RAM, just to go out and buy a SAMS card.  And so many of the programs use VRAM as a resource, rather than waste it because it isn't system RAM.  (Edit: SAMS doesn't work with the Geneve, so VRAM also helped to bridge memory gaps between the 4A and Geneve)

 

Another challenge is that 80 column mode requires twice the screen image memory.   One common solution to simplify conversion and/or support 40 & 80 column systems was to shift the pattern table into another bank so that the screen image could be expanded in its current location. Finding a free 2K contiguous space along table boundaries is challenging, especially if the programmer used VDP disk IO and ram for internal buffers, storage, etc.  I ran into this with a few programs I wanted to convert for F18A usage.  

 

When I enhanced TIMXT using the F18A 80-column+color mode, it was a challenge to fit the screen table, pattern table, attributes table(color), file transfer buffers (disk controllers use VDP!), RS232 ring buffer, and GPU code into VRAM.  I ended up having to mask a few lines of the screen table where it overlapped another table. Admittedly, that case was a bit more extreme than others

 

 

[matthew180]

For sure, I totally sympathize with the situation and *why* developers used the VRAM, it just feels like a continuation of the bad hardware design choices to provide a bunch of RAM behind the slow 8-bit interface of the VDP.  It seems by the time the 80-column cards came around that a common / generic memory expansion would also have been available?  Maybe not.  But there is nothing particularly special or magic about memory mapping, and the 128K on the 80-column card would have cost the same if it was put on a memory expansion card.  I don't know much about the 99/4A beyond the PEB and about 1984 or so, so my opinions are probably born from a bit of ignorance as well.

[+Ksarul]

The various 80-column options all came out before the SAMS (then titles the AEMS) was available, and it was pretty much the first general-purpose expansion to come out that gave the user access to seriously expanded memory. The Myarc card with its 128K OS came out earlier, but it really wasn't a general purpose expansion, it was only an expansion that could be tweaked to work as one. About the only application that ever took advantage of that tweaking capability was Myarc Extended BASIC II.

 

By the time SAMS was on the street, most of the programs that took advantage of 80-columns were already written. SAMS really didn't reach a critical mass of community penetration until many years later--so software supporting it was slow in coming. That isn't the case anymore, as a lot of new software looks for it and knows what to do with it when it finds it.

[Cobalt Tiger]

Hi

 

Where do I purchase these boards from?

I'd like to buy 3. one from my Powertran Cortex 2, one for my TI99/4A and a spare.

 

Best Regards

 

Danny

[matthew180]

@Cobalt Tiger The MK2 is not done yet.  When they are available, you will be able to purchase them from my web store, and possibly other places (undetermined at this time).

 

Update:

I have spent the better part of the last 3 to 4 weeks working (fighting, pulling of hair, crying, etc.) on the digital video output, and I finally have it working and tested.  I am now able to work on decoupling the scan-line generation from the pixel scan-out, which is required to support the digital video, and was also a not-so-good design on my part.

 

Since much of the HDL was created while I was also learning VHDL and FPGAs, a lot of design decisions were made with limited knowledge and information, and some of the design needs to change so I can advance the HDL for the MK2 features.  I am trying to keep the changes limited to the essentials so I can get the MK2 out as quickly as possible, with future updates planned.