Jump to content

Recommended Posts

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

 

mk2_k_working_10x7.thumb.jpg.ab2883934340812698841a891ab4a45c.jpg

 

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:

 

msg-24952-0-02647500-1543474963_thumb.jpg

 

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.

 

 

 

  • Like 8

Share this post


Link to post
Share on other sites

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

  • Like 2

Share this post


Link to post
Share on other sites
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?

 

 

  • Like 2

Share this post


Link to post
Share on other sites
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.

 

  • Like 1

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites

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.  

Share this post


Link to post
Share on other sites
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.

 

  • Like 2

Share this post


Link to post
Share on other sites

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

 

I was just using it as a reference, though.

Share this post


Link to post
Share on other sites

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?

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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: 

 

Share this post


Link to post
Share on other sites
Posted (edited)
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 by Ikrananka

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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,

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...