9640News

Every time I see there is a new post here, I get nervous opening up to see what may be posted......

For those following this thread, this is part of what I sent the @InsaneMultitasker on a request he had made. Been reviewing the code where a user would type the ampersand (&) at the CLI prompt. Two things happen here. The CLI code essentially does a CLR @>F110 and does a BLWP @0. It is during this point, all the XOP's run their powerups again. In L8\DSRPASS-S, there is this note for the DSR: ; AORG >2000: ; Pointers to parameters (how are they used?) ; XOP->Powerup for DSR. Reset rs232 redirect. Clears SCSI and DSR buffers. ; Branches to >6000 (HD.FLPPRM) to powerup HFDC/read DIPs/set emulate ; Configures Floppy controller, clears spooler, init RS232 & buffers ; Returns via PWRUP7 So, regardless, the HFDC light and drive is going to flash and it looks like it checks to see if there is an emulate file if a HFDC exists in the system. I'm not of the opinion we should go messing with this code. Next, there is a flag set (SETO @NEWAUT) when the ampersand is originally entered at the CLI in the CLI\HCLIS code after the DOSCMD label. Following the detection of the ampersand, the text (if any) is parsed based on the current file path and added to a modifying AUTOEXEC pab. When the NEWAUT flag setting is hit, it then tries to load a file that was parsed. So, if it is just an ampersand, then it is a filepath with no filename. Thus, no DV80 file can be opened. This is where I have added code that looks at the length of filename, and then looks at the last character of the parsed filename. If it is a period, then it is just a filepath so I jump around the code that would try to open the DV80 autoexec file.

Well, my test code last night did not work. Need to do some more chasing of the code.

I believe the fix for the & entry can be fixed in CLI\HCLIS. There is an error return if the file is not found which would be the case if it was a device/path entry only without filename. I haven't had time to test, but my thoughts were to read the length byte of the path, and then compare the last character in the PAB to a "." and if it is the period, then bypass the check. That would avoid the device read. I need to look over the register usage prior to the XOP call to make sure the test doesn't corrupt a needed register.

Thanks for the offer but I will wait for @Ksarul board. I need to chase down something that needs access to the bus and power. Not sure where the issue is, but on my Memex Geneve, the onboard 32K ram is not being accessed so the Geneve is limited to MDOS 2.21.

Thanks for the offer. I’m not in any hurry, so I can wait until they are available. I’ve got enough other things going on to keep me busy.

Let me know when you have them available. Thanks

Might be nice if someone translated that to more readable line statements.......

Does anyone offer an extension "card" that can be placed in the PEBox so that a card can then be plugged into it above the top of the PEBox case? That way, a volt/ohm meter can be used to access the card for diagnostic purposes?

I will look into it. I should have some time this week as I am on 8 hour days instead of 10, and, it will be rainy weather this week.

It's been a long time, but I thought the format command in MDM5 may have needed the 32K chip to format a 1.44 MB floppy.

Show your AUTOEXEC. I assume you are using MDOS 7.30?

Remove the ECHO statement from your AUTOEXEC.

I'm tagging @InsaneMultitasker on this thread in the event he did not see this message.

While it is an SD card in the DREM, the speeds for access are pretty much the same. The big difference is if I pull the SD card and place in a Windows computer, I can backup the Drem in about 1 minute.