Force Command : kinda like command.com from 1985 (no TIPI required!)

[+mizapf]

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 October 22, 2020 by mizapf

[+9640News]

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 October 22, 2020 by BeeryMiller

[+jedimatt42]

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!

 

 

[Omega-TI]

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! ?

[+mizapf]

@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?

[+jedimatt42]

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. 

[+InsaneMultitasker]

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

[Jeff White]

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

 

 

[+9640News]

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

[+jedimatt42]

 

More work has been done with the API. allowing for the FTP code to be re-implemented as an external command. 

Publishing now, so the REDO command recall can be used. 

 

FTP can be loaded from the PATH - it is included in the ZIP under FC.BIN.

PATH can be set per the examples this post: 

 

 

The FTP command supports a hostname and port argument... like:

FTP 192.168.1.105 21

( I don't remember 21 being a default, but it should be, will be if it isn't... ) 

 

A preview of using the API is visible here: https://github.com/jedimatt42/fcmd/tree/master/example/gcc

 

 

[+jedimatt42]

Oops, I left the big ROM file out of the zip, cause I had renamed it for experiments with emulators...  

 

I've re-uploaded the zip with the rom back in... and an RPK for js99er or MAME use.

[+9640News]

Matt,

 

I know you released a standalone version of the FTP client some time ago and you have your latest release.  Got a question based on another question a user asked in the MDOS 7.00 thread.

 

Will your newest release, and/or the older standalone release that worked on the Geneve in Rompage mode, allow one to to do a FTP transfer from a WDS1/HDS1/IDE1/SCS1 device  to a TIPI path?  More specifically, if it is a FTP GET * (I think that is the context, though not 100% sure), would it copy all files and directories from one place to the other?

 

What I am wondering is if the FTP client can be used as a backup tool from one device to the other with it creating sudirectories, etc. on the fly as needed with wildcard functionality?  I think the answer is no, but wanted to check.

 

There may be a tool, though not 100% sure, that may already have the capability (HardBack) to backup to the TIPI, but not sure how if it does direct sector I/O that would prevent it from working or not.  

Beery

 

[klrw111-78]

Upgraded to 1.2 yesterday on the fg99.  Tried to access DSK5 on the RAM disk, but it would not take it or CRU.DSK5 for a dir or cd command.  Loaded DM2K and it had no problem with DSK5.  Does FC work with HRD400B ram disks?

[+jedimatt42]

9 hours ago, BeeryMiller said:

Matt,

 

I know you released a standalone version of the FTP client some time ago and you have your latest release.  Got a question based on another question a user asked in the MDOS 7.00 thread.

 

Will your newest release, and/or the older standalone release that worked on the Geneve in Rompage mode, allow one to to do a FTP transfer from a WDS1/HDS1/IDE1/SCS1 device  to a TIPI path?  More specifically, if it is a FTP GET * (I think that is the context, though not 100% sure), would it copy all files and directories from one place to the other?

 

What I am wondering is if the FTP client can be used as a backup tool from one device to the other with it creating sudirectories, etc. on the fly as needed with wildcard functionality?  I think the answer is no, but wanted to check.

 

There may be a tool, though not 100% sure, that may already have the capability (HardBack) to backup to the TIPI, but not sure how if it does direct sector I/O that would prevent it from working or not.  

Beery

 

No, the old FTP EA5 code would need much more work to do any kind of recursive copy. And it does not copy from TIPI to TI. It copies from an FTP server to the TI. The new versions doesn't move the ball in that direction either.

[dgrissom]

More work has been done with the API. allowing for the FTP code to be re-implemented as an external command. 

Publishing now, so the REDO command recall can be used. 

 

I appreciate the REDO key.  It seems to work well!

 

I will test this more in the morning!

 

So far its GOOD!

[+jedimatt42]

2 hours ago, klrw111-78 said:

Upgraded to 1.2 yesterday on the fg99.  Tried to access DSK5 on the RAM disk, but it would not take it or CRU.DSK5 for a dir or cd command.  Loaded DM2K and it had no problem with DSK5.  Does FC work with HRD400B ram disks?

I tested it months ago with the MAME Horizon Ramdisk emulation using what I think was latest ROS DSR.  I will have to try that again, but I haven't changed anything at that level. 

 

Try the 'drives' command. What do you see?

 

Some portions may be more strict requiring a '.' at the end of a device name or directory.

[+jedimatt42]

1 hour ago, jedimatt42 said:

I tested it months ago with the MAME Horizon Ramdisk emulation using what I think was latest ROS DSR.  I will have to try that again, but I haven't changed anything at that level. 

 

Try the 'drives' command. What do you see?

 

Some portions may be more strict requiring a '.' at the end of a device name or directory.

 

Expected hardware compatibility is documented on this page: https://github.com/jedimatt42/fcmd/wiki/Compatibility

 

OS updates or something broke my MAME, so retesting generic HRD compatibility will take me a while. HRD devices have a soft-DSR, so compatibility with Force Command can break with any ROS update also. When I get the HRD emulation running again, I'll document the version of ROS it was tested with. 

[atrax27407]

The Horizon emulation is broken in MAME V225

[+InsaneMultitasker]

4 hours ago, jedimatt42 said:

HRD devices have a soft-DSR, so compatibility with Force Command can break with any ROS update also

Most recent ROS release is in post #1 of the Horizon dev topic; no published changes since 3.27.2020.   @ mention me or post in dev if something needs to be looked at following testing.

[klrw111-78]

I tested it months ago with the MAME Horizon Ramdisk emulation using what I think was latest ROS DSR.  I will have to try that again, but I haven't changed anything at that level. 
 
Try the 'drives' command. What do you see?
 
Some portions may be more strict requiring a '.' at the end of a device name or directory.

The drives command shows all active cards with crus including cru 1400 with all ram disks including the calls setup in ROS842C


FC 0.M addresses the drives and works as it should, but fails in versions 1.1 and 1.2


Sent from my iPad using Tapatalk

[+jedimatt42]

4 hours ago, klrw111-78 said:

The drives command shows all active cards with crus including cru 1400 with all ram disks including the calls setup in ROS842C


FC 0.M addresses the drives and works as it should, but fails in versions 1.1 and 1.2


Sent from my iPad using Tapatalk

Ok, I must have inadvertently broken something. 

 

Hopefully I can get my MAME working again tonight. Supporting things you don't use yourself is always a bad idea. But, that is the road I went down.

[+jedimatt42]

 

So, I got my MAME (ver 220) working again... ROS842C loaded up... and the latest Force Command seems to work fine with it. 

 

`CD DSK5` works, `CD DSK5.` works... I was still able to copy a disk full of junk to a ROS drive. DIR it, and such... 

Note, you do not have a device name conflict for your ROS drives, so you should not need to use the crubase naming scheme to disambiguate. You do have name conflicts with the TIPI, IDE and Floppy controllers DSK1, DSK2, and DSK3... so those are the only times Force Command might need you to specify the CRUBASE... 

 

Force Command's LOAD command doesn't seem to agree with ROS's CFG1 anymore.  I think it hangs when detecting SAMS... cause if SAMS is there, I have it all enabled and in use... I need to fix my LOAD command to turn SAMS back off and reset the default bank mapping.

 

[klrw111-78]

6 hours ago, jedimatt42 said:

 

So, I got my MAME (ver 220) working again... ROS842C loaded up... and the latest Force Command seems to work fine with it. 

 

`CD DSK5` works, `CD DSK5.` works... I was still able to copy a disk full of junk to a ROS drive. DIR it, and such... 

Note, you do not have a device name conflict for your ROS drives, so you should not need to use the crubase naming scheme to disambiguate. You do have name conflicts with the TIPI, IDE and Floppy controllers DSK1, DSK2, and DSK3... so those are the only times Force Command might need you to specify the CRUBASE... 

 

Force Command's LOAD command doesn't seem to agree with ROS's CFG1 anymore.  I think it hangs when detecting SAMS... cause if SAMS is there, I have it all enabled and in use... I need to fix my LOAD command to turn SAMS back off and reset the default bank mapping.

 

OK, thanks for checking.  I'll just go back to the earlier version that works with my hardware.

[+jedimatt42]

2 hours ago, klrw111-78 said:

OK, thanks for checking.  I'll just go back to the earlier version that works with my hardware.

Maybe someone else on here has an HRD4000B, and can confirm the failure?

[+arcadeshopper]

I'll try it

Sent from my LM-V600 using Tapatalk