Jump to content
jedimatt42

Force Command ver 1.1 : kinda like command.com from 1985

Recommended Posts

One good way is to read status register 4 of the 9938. The contents look like 1111111x. The 9918 ignores any attempt to set a status register number and will return its only status register.

 

Edit, to elaborate a bit more:

 

The number of the status register must be set in video register 15. This register does not exist on the 9918/28, so it will ignore this setting. Also, the 9918/28 only has a single status register whose bits are [ F | S5 | C | Sn | Sn | Sn | Sn | Sn ]. F is the VSYNC, S5 is 1 if there are 5 sprites on a line, C is the collision flag, and Sn is the 5-bit sprite number of the 5th sprite. If you don't have five sprites on a line, the contents will never look like 1111111x, as does status register 4 of the 9938/9958.

 

So once you know it is a 9938/9958, you can tell both apart using status register 2: [ FL | LP | ID | ID | ID | ID | ID | FH ]. The five ID bits are 00000 for the 9938. As far as I remember, the 9958 has ID=00010.

 

Edited by mizapf
  • Like 2

Share this post


Link to post
Share on other sites
14 hours ago, jedimatt42 said:

I'll add @BeeryMiller, I would like to support 8838 80 column mode. I do test in Mame and classic99 often enough that it would be nice...  

 

I don't know off hand how to detect 9938/58 - I do recall some chatter in the F18A threads about it though... - I assume I could use the 9th instead of 5th sprite limit to detect.

 

 

Implementing 80 column text mode would be great!!! 

 

Who knows, you may want to add 80 column text to your telnet client as well <wink>. On the MDOS side of things, ANSI color has been implemented with PORT and MyTERM as I am sure you are aware.  Color was implemented, however it was done using the MDOS Video XOP calls in graphics mode 6.  If you can pull off color mode on a 9938, I suspect that would be some significant code.  It could probably be done as the MDOS Video XOP source is all out there to minimize some coding, but incorporating it into a FinalGrom configuration would be a major undertaking.  As it is, people calling ANSI BBS's with telnet clients are very few and doubtful the effort justify the time and effort.

 

Beery

Edited by BeeryMiller

Share this post


Link to post
Share on other sites
4 hours ago, BeeryMiller said:

 

 

Implementing 80 column text mode would be great!!! 

 

Who knows, you may want to add 80 column text to your telnet client as well <wink>. On the MDOS side of things, ANSI color has been implemented with PORT and MyTERM as I am sure you are aware.  Color was implemented, however it was done using the MDOS Video XOP calls in graphics mode 6.  If you can pull off color mode on a 9938, I suspect that would be some significant code.  It could probably be done as the MDOS Video XOP source is all out there to minimize some coding, but incorporating it into a FinalGrom configuration would be a major undertaking.  As it is, people calling ANSI BBS's with telnet clients are very few and doubtful the effort justify the time and effort.

 

Beery

 

My plan is to rewrite my TELNET as an extension of Force Command. 

Existing TELNET client will stand as is, as delivered with TIPI - it isn't for BBS'ing, it is for TIPI management. 

 

I'm totally unaware of MyTERM and PORT. I'm not a BBS'er, so I haven't explored terminal emulators that exist on 4A and 4A adjacent platforms. 

 

I'd be more interested in supporting the color attributes for programs I write as extensions of ForceCommand.   Force Command's API supports sending ANSI codes to the display, but presently, color is ignored for 40x24 mode, and the F18A is utilized for 80x30 mode. 

 

I managed to get mame setup as a EVPC 4A. So I can test... but I can't read a status register to save my life... (spoiler, I figured it out by explaining it to you all) I have C code that reproduces the algorithm @InsaneMultitasker suggested. Worked great. But trying to implement @mizapf suggesting, which I like as it doesn't write, and just seems simpler... But this code, generated from gcc just isn't doing it:

 

detect_vdp
        ; wrong port number ---  li   r2, >8C00    ; load up VDPWA port
        li   r2, >8C02    ; load up VDPWA port
        li   r4, >48F     ; select status register 0x04
        movb r4, *r2      ; -- push the 0x04 to VDP
        swpb r4
        movb r4, *r2      ; -- push the 0x8F (write to register 15) to VDP
        movb @>8802, r1   ; Read from status register port
        li   r3, >8F      ; select status register 0x00 to restore prior state
        movb r3, *r2      ; -- push 0x00 to VDP
        swpb r3     
        movb r3, *r2      ; -- push write to register 15 to VDP
        srl  r1, 8        ; convert the byte in top of r1 to an int for C.
        b    *r11

 

On the evpc, I get 0x0084, on the normal 4A I get 0x009F  both in mame.   I'm in 40 column mode already, so there are no sprites.. I would have expected the 4A to return nothing greater than 0x1F. And as was said, the 9938 should have returned 0xFF or 0xFE

limi 0 is the state of affairs, and garbage ends up on the display.. so I feel like I'm using the wrong port to write to the register... 00ops, yep, that is it... Ok, now I get 0xFE on the EVPC, but on the 4A, I can't read what I get cause the screen gets turned off... Probably not a problem if I detect prior to setting up the screen.

 

Oh, well... now I'm late for the day job... at least there is no commute. 

 

Thanks!

 

 

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, jedimatt42 said:

My plan is to rewrite my TELNET as an extension of Force Command. 

Damn, you really know how to get a person's attention! 👍

Share this post


Link to post
Share on other sites

@jedimatt42: What happens on the 4A when you say the screen is turned off? Does it become empty (with some color) or black? Could it be that the 9918 mistakes register 15 as register 7 (ignoring the leftmost bit) so your writing of 00 gets loaded into register 7?

  • Like 2

Share this post


Link to post
Share on other sites
5 hours ago, mizapf said:

@jedimatt42: What happens on the 4A when you say the screen is turned off? Does it become empty (with some color) or black? Could it be that the 9918 mistakes register 15 as register 7 (ignoring the leftmost bit) so your writing of 00 gets loaded into register 7?

 

Yep, it goes black, so reading the datasheet, that is most likely what happened.   I didn't explore this morning :)  

In Force Command, I have a color command... so I can just type COLOR 15 and all my text becomes white again :)

 

All as designed... my intention is to use before the screen is setup, so everything will be healed and the VDP type will be held. 

Share this post


Link to post
Share on other sites
On 10/22/2020 at 3:08 PM, mizapf said:

@jedimatt42: What happens on the 4A when you say the screen is turned off? Does it become empty (with some color) or black? Could it be that the 9918 mistakes register 15 as register 7 (ignoring the leftmost bit) so your writing of 00 gets loaded into register 7?

I wonder if this behavior explains what (at the time) I thought was a failure of tests I had tried to mimic.  I'll have to revisit the various routines as I do like the status register approach.  (Side note: I might still use a memory-based approach to determine if there is expansion vram available to the 9938/58, which isn't really relevant for FC at present). 

Share this post


Link to post
Share on other sites
On 21 October 2020 at 7:59 PM, BeeryMiller said:

I thought years ago, Jeff White may have written some code to detect the difference between a 9918 and a 9938.  Not sure about detecting a 9958.  @InsaneMultitasker might know if there is a test routine somewhere. 

 

 

According to the source code, 1991.  You can find my VDPID and bonus CPUID included here:  https://ftp.whtech.com/datasheets%20and%20manuals/Hardware/ti%20hardware%20compendium.txt

 

 

  • Like 2

Share this post


Link to post
Share on other sites
1 hour ago, Jeff White said:

According to the source code, 1991.  You can find my VDPID and bonus CPUID included here: https://ftp.whtech.com/datasheets and manuals/Hardware/ti hardware compendium.txt

 

 

Thanks.  At least that was one fragment of my memory that wasn't corrupt <grin>.  I was pretty sure you had some code that checked for the type of VDP, just didn't know where the code could be found.


Beery

  • Like 2

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