Setting MESS using QMC2

[+mizapf]

Can you upload a copy of that disk image?

[RXB]

Can you upload a copy of that disk image?

Sure here is my entire Disk Collection on MESS currently.

disks.zip

Edited June 20, 2014 by RXB

[TheMole]

Sure here is my entire Disk Collection on MESS currently.

I don't see the attachment.

[RXB]

I don't see the attachment.

For some reason it did not send it?

disks.zip

Edited June 20, 2014 by RXB

[+mizapf]

I can unprotect them and delete them with RXB but TI IMAGE TOOL will not do anything to that DISK?

Which disk image in your collection is the one which TIImageTool is unable to work with?

 

Just to make sure - you closed your images in TIImageTool before you go into MESS? Because if you keep them open in TIImageTool and modify them inside MESS, you can corrupt their contents. TIImageTool does not check for concurrent changes.

[Willsy]

Also note that classic99 disk emulation is not as accurate as MESS. I can personally confirm this. I had the disk functions in TurboForth working for ages in classic99 without issue before trying them in MESS. MESS crashed horribly. I tried it on real iron. Exactly the same as MESS. Classic99 is generally more forgiving because it has its own virtual disk controller (as I understand it).

 

IIRC Tursi added an option to classic99 to provide stricter disk emulation. Check the docs.

 

Mark

Edited June 20, 2014 by Willsy

[RXB]

Which disk image in your collection is the one which TIImageTool is unable to work with?

 

Just to make sure - you closed your images in TIImageTool before you go into MESS? Because if you keep them open in TIImageTool and modify them inside MESS, you can corrupt their contents. TIImageTool does not check for concurrent changes.

Oddly if I shut down MESS and TI IMAGE TOOL then it works on the disks correctly so if MESS is open TI IMAGE TOOL does not work properly.

That is odd as normally I use Ti99Dir and Classic99 for a couple of years now and this is a odd change.

If I get my RXB 2012 re -written to run on MESS with Hard Drive this will be a advantage not a disadvantage any more.

 

This may explain why RXB worked with FCOPY and yet TI IMAGE TOOL refused to work on that DSK

[RXB]

Also note that classic99 disk emulation is not as accurate as MESS. I can personally confirm this. I had the disk functions in TurboForth working for ages in classic99 without issue before trying them in MESS. MESS crashed horribly. I tried it on real iron. Exactly the same as MESS. Classic99 is generally more forgiving because it has its own virtual disk controller (as I understand it).

 

IIRC Tursi added an option to classic99 to provide stricter disk emulation. Check the docs.

 

Mark

The RXB disk utilities were all written for RXB 2001 long before any Emulator was created or released.

 

I have pulled up a source code list of all the RXB Disk Utilities from 2001 and 2012 and they are exactly the same.

 

So when people say it has to be RXB doing something wrong then why did it work fine in SCSI and others said fine on the HFDC yet now has a issue?

 

On WIN994a I found that the Hard Drive is named HDK# so that is why it crashes on RXB as I only included DSK# or WDS# or SCS#

 

Thus I intend to release a updated RXB that will fix this issue along with any other errors people find in RXB.

[RobertLM78]

While you are fixing RXB, if you can figure a way out to have your cake and eat it too, I'd like to see the 'REDO' function in RXB. I've been using RXB more and more, but I still very much miss the 'REDO' function .

 

(I'm sure you hear that all the time, but I thought I'd throw in my two cents ).

[+InsaneMultitasker]

The RXB disk utilities were all written for RXB 2001 long before any Emulator was created or released.

 

I have pulled up a source code list of all the RXB Disk Utilities from 2001 and 2012 and they are exactly the same.

 

So when people say it has to be RXB doing something wrong then why did it work fine in SCSI and others said fine on the HFDC yet now has a issue?

 

On WIN994a I found that the Hard Drive is named HDK# so that is why it crashes on RXB as I only included DSK# or WDS# or SCS#

 

Thus I intend to release a updated RXB that will fix this issue along with any other errors people find in RXB.

Rich,

There are a few answers and possibilities I see:

1. The SCSI DSR may have changed to be more compatible with the HFDC. The older versions of the EPROM have slowly been replaced by Richard over the last 15 years.

2. The 0x8352 problem I mentioned and that Michael tested would only show up if the value in 0x8352 was NOT clear. It is possible earlier versions of the DSRs or of RXB were clearing this value, so that the bug was not easily apparent. I am not saying your code was flawed, only that your tests and others may have relied upon different versions. Even testing on the real iron may have produced a working test one time and failed when you set FAC8 in one of your other routines. Notice the value Michael inspected is set elsewhere in your routines.

3. I thought the HDK# device looked like a hard drive but had different internal structures. If so, RXB may not work regardless of your changes. You'll need to test and verify as you make changes.

4. SCSI and IDE cards are slightly different in operation from the HFDC. Subroutines like "change directory opcode 0x27" report errors differently; this caused some trouble with programs written for the HFDC. Your sector and direct file IO commands will NOT work with the IDE card without modifying the opcodes. Fred chose to use 8x versus 2x to avoid coexistence problems with HFDC and SCSI.

 

Like the rest of us you'll find some tweaking may be necessary. There are people here who support emulation, the emulators, and the real hardware so there is a good chance of identifying most problems. It may just require persistence to get to the root cause(s).

[RXB]

While you are fixing RXB, if you can figure a way out to have your cake and eat it too, I'd like to see the 'REDO' function in RXB. I've been using RXB more and more, but I still very much miss the 'REDO' function .

 

(I'm sure you hear that all the time, but I thought I'd throw in my two cents ).

It might be possible, but the Redo buffer is smaller than the Token Buffer that the actual program you type in is stored.

 

See CALL CLEAR takes 7 bytes to store in the Token buffer but in the REDO Buffer it takes up 14 bytes.

 

The REDO buffer is 152 bytes in size, but the Token buffer is 163 bytes in size.

 

You can see why the REDO buffer sucks to recall an entire line typed in huh?

[RXB]

Rich,

There are a few answers and possibilities I see:

1. The SCSI DSR may have changed to be more compatible with the HFDC. The older versions of the EPROM have slowly been replaced by Richard over the last 15 years.

2. The 0x8352 problem I mentioned and that Michael tested would only show up if the value in 0x8352 was NOT clear. It is possible earlier versions of the DSRs or of RXB were clearing this value, so that the bug was not easily apparent. I am not saying your code was flawed, only that your tests and others may have relied upon different versions. Even testing on the real iron may have produced a working test one time and failed when you set FAC8 in one of your other routines. Notice the value Michael inspected is set elsewhere in your routines.

3. I thought the HDK# device looked like a hard drive but had different internal structures. If so, RXB may not work regardless of your changes. You'll need to test and verify as you make changes.

4. SCSI and IDE cards are slightly different in operation from the HFDC. Subroutines like "change directory opcode 0x27" report errors differently; this caused some trouble with programs written for the HFDC. Your sector and direct file IO commands will NOT work with the IDE card without modifying the opcodes. Fred chose to use 8x versus 2x to avoid coexistence problems with HFDC and SCSI.

 

Like the rest of us you'll find some tweaking may be necessary. There are people here who support emulation, the emulators, and the real hardware so there is a good chance of identifying most problems. It may just require persistence to get to the root cause(s).

I wrote Sector working with SCSI cards to support up to >FFFFFFFF sectors.

But I only supported 256 byte size sectors, so I may have to modify it to support 256 to 1024 byte sectors.

 

All sectors are passed to the Lower 8K as a buffer so using 256 byte sectors allows 32 sectors each pass for a copy.

If I increase it to 1024 in the Lower 8k would be only 8 sectors per pass for a copy.

I also use the SAMS so can read 1024Meg per pass with my sector copy program using the SAMS and a hard drive.

 

I am more then a little pissed that every freaking card can not maintain any form of standards on using TI GPL Devices File Access or any standards.

[RobertLM78]

It might be possible, but the Redo buffer is smaller than the Token Buffer that the actual program you type in is stored.

 

See CALL CLEAR takes 7 bytes to store in the Token buffer but in the REDO Buffer it takes up 14 bytes.

 

The REDO buffer is 152 bytes in size, but the Token buffer is 163 bytes in size.

 

You can see why the REDO buffer sucks to recall an entire line typed in huh?

I do see - I was just busting your balls, anyway . Actually, with the COPY command the REDO function seems a bit less necessary. And RXB has a lot of other cool commands already built in, too. I just have to think outside the box.

[RXB]

I do see - I was just busting your balls, anyway . Actually, with the COPY command the REDO function seems a bit less necessary. And RXB has a lot of other cool commands already built in, too. I just have to think outside the box.

Well looking at the code I might be able to put it back in but at the sacrifice of many many cool features like USER Batch file processing and DOS like environment.

[RobertLM78]

Well looking at the code I might be able to put it back in but at the sacrifice of many many cool features like USER Batch file processing and DOS like environment.

And honestly, I think those are way more useful features than a REDO. It would be cool to have both, but if the choice came down to having things like a user batch file and a DOS-like environment or a REDO, I would definitely chose the former myself, rather than the latter . One of the features I have used REDO for in the past is copying lines - and that's something that COPY takes care of quite nicely .

[RXB]

Rich,

There are a few answers and possibilities I see:

1. The SCSI DSR may have changed to be more compatible with the HFDC. The older versions of the EPROM have slowly been replaced by Richard over the last 15 years.

2. The 0x8352 problem I mentioned and that Michael tested would only show up if the value in 0x8352 was NOT clear. It is possible earlier versions of the DSRs or of RXB were clearing this value, so that the bug was not easily apparent. I am not saying your code was flawed, only that your tests and others may have relied upon different versions. Even testing on the real iron may have produced a working test one time and failed when you set FAC8 in one of your other routines. Notice the value Michael inspected is set elsewhere in your routines.

3. I thought the HDK# device looked like a hard drive but had different internal structures. If so, RXB may not work regardless of your changes. You'll need to test and verify as you make changes.

4. SCSI and IDE cards are slightly different in operation from the HFDC. Subroutines like "change directory opcode 0x27" report errors differently; this caused some trouble with programs written for the HFDC. Your sector and direct file IO commands will NOT work with the IDE card without modifying the opcodes. Fred chose to use 8x versus 2x to avoid coexistence problems with HFDC and SCSI.

 

Like the rest of us you'll find some tweaking may be necessary. There are people here who support emulation, the emulators, and the real hardware so there is a good chance of identifying most problems. It may just require persistence to get to the root cause(s).

Ok I pulled out the SCSI documents that I used to make the Disk/Hard drive utilities in RXB.

>8350 & >8352 is 32 bit address of sector number to read/write

This means the sector number is in >8352 if under >FFFF so if I clear this word then ONLY sector zero (0) will be read and no other sector?

How would I read sector 83 if I have to put >0000 in >8352 instead of the sector I want to read?

 

Now in the HFDC documents it says:

>8350 Sector number

>8352 MSB Sector Number

QUOTE: In the case of hard drive the word at >8352 must also be defined as the most significant word of the 32 bit sector definition.

Again this means if I clear >8352 before access then ONLY sector zero (0) will be read and no other sector?

 

So something has been changed so GPL will not work properly. How am I suppose to clear >8352 if that is the sector I want to read or write?

Also ERROR codes are return in >8350 and I check this for the error value there. So unless Zero is in that byte the DSR errored out?

Edited June 21, 2014 by RXB

[+InsaneMultitasker]

Ok I pulled out the SCSI documents that I used to make the Disk/Hard drive utilities in RXB.

>8350 & >8352 is 32 bit address of sector number to read/write

This means the sector number is in >8352 if under >FFFF so if I clear this word then ONLY sector zero (0) will be read and no other sector?

How would I read sector 83 if I have to put >0000 in >8352 instead of the sector I want to read?

 

Now in the HFDC documents it says:

>8350 Sector number

>8352 MSB Sector Number

QUOTE: In the case of hard drive the word at >8352 must also be defined as the most significant word of the 32 bit sector definition.

Again this means if I clear >8352 before access then ONLY sector zero (0) will be read and no other sector?

 

So something has been changed so GPL will not work properly. How am I suppose to clear >8352 if that is the sector I want to read or write?

Also ERROR codes are return in >8350 and I check this for the error value there. So unless Zero is in that byte the DSR errored out?

 

The SCSI documentation is misleading.

0x8350 is defined as the 'lower' 16 bits of the sector to maintain compatibility with the floppy sector routine. Here are a few examples using a 32-bit value for the sector number you want to read/write:

 

Sector# 0x8350 0x8352

00000200 0200 0000

00013000 3000 0001

00020001 0001 0002

 

The reason I inquired about clearing 0x8352 earlier is because the requested sector number was less than 65535 (0xFFFF). Michael's debugging showed 8352 contained a non-zero entry. Now, if the requested sector is larger than 65535, then 0x8352 would not be zero and would follow the examples above.

 

(Edit: should this conversation be moved to a new thread)

Edited June 21, 2014 by InsaneMultitasker

[RXB]

Oh my, took me some time to write this test program. I think I found all possible pitfalls* ...

 

But it is working, at least in MESS. This program reads a sector specified in SECTOR from the first hard disk and displays the contents on the screen.

 

 

       DEF  START
       REF  DSRLNK,VMBR,VMBW
 
WS     BSS  32
BUF    BSS  256
 
SECTOR DATA 0
 
PAB    BYTE 1
       BYTE >20
 
START  LIMI 0
       LWPI WS
       LI   R0,>1000
       LI   R1,PAB
       LI   R2,2
       BLWP @VMBW
       MOV  R0,@>8356
 
       LI   R0,>0101
       MOV  R0,@>834C
       LI   R0,>1800
       MOV  R0,@>834E
       MOV  @SECTOR,@>8350
       CLR  @>8352
 
       BLWP @DSRLNK
       DATA 10
 
       LI   R0,>1800
       LI   R1,BUF
       LI   R2,256
       BLWP @VMBR
 
       CLR  R0
       BLWP @VMBW
 
       LIMI 2
       JMP  $
 
       END

*Pitfalls: You can do the following to make life harder:

 

Forget to write a PAB at all

Forget to put the pointer in 8356

Put the wrong pointer in 8356

Try to address the first drive as number 0 (manual says they start at 1)

 

I just noticed this is a DISK access and not Hard Drive access.

RXB SECTOR works fine on SECTOR access to DISK.

It is Hard Drive that fails and says File Error.

[RXB]

 

The SCSI documentation is misleading.

0x8350 is defined as the 'lower' 16 bits of the sector to maintain compatibility with the floppy sector routine. Here are a few examples using a 32-bit value for the sector number you want to read/write:

 

Sector# 0x8350 0x8352

00000200 0200 0000

00013000 3000 0001

00020001 0001 0002

 

The reason I inquired about clearing 0x8352 earlier is because the requested sector number was less than 65535 (0xFFFF). Michael's debugging showed 8352 contained a non-zero entry. Now, if the requested sector is larger than 65535, then 0x8352 would not be zero and would follow the examples above.

 

(Edit: should this conversation be moved to a new thread)

Again RXB SECTOR works perfectly with DISK, it only fails on HFDC on MESS.

 

RXB SECTOR works like this

Path: WDS3.

Read/Write Flag: Any number is read, only will write if zero (0) in read/write flag. So any number other than 0 will set to read only.

#sectors: Number of sectors to read or write to lower 8k. Range is from 1 to 32 sectors using 256 byte sectors.

SECTOR: Hex string range is from "00000000" to "FFFFFFFF"

 

CALL SECTOR("WDS3.",8,32,"00000000")

This converts the "00000000" into a hex value of >0000 + >0000 and put that into >8350 & >8352

 

How could any value but zero be in >8350 and >8352?

 

Another problem is the size of the sectors. RXB SECTOR uses 256 byte sectors only. Is MESS HFDC using 512 bytes sectors?

 

Also I can find no reference in SCSI or HFDC documents that >8352 must be cleared to zero? (Yes DISK would require this, but not HFDC or SCSI)

[+InsaneMultitasker]

Again RXB SECTOR works perfectly with DISK, it only fails on HFDC on MESS.

 

RXB SECTOR works like this

Path: WDS3.

Read/Write Flag: Any number is read, only will write if zero (0) in read/write flag. So any number other than 0 will set to read only.

#sectors: Number of sectors to read or write to lower 8k. Range is from 1 to 32 sectors using 256 byte sectors.

SECTOR: Hex string range is from "00000000" to "FFFFFFFF"

 

CALL SECTOR("WDS3.",8,32,"00000000")

This converts the "00000000" into a hex value of >0000 + >0000 and put that into >8350 & >8352

 

How could any value but zero be in >8350 and >8352?

 

Another problem is the size of the sectors. RXB SECTOR uses 256 byte sectors only. Is MESS HFDC using 512 bytes sectors?

 

Also I can find no reference in SCSI or HFDC documents that >8352 must be cleared to zero? (Yes DISK would require this, but not HFDC or SCSI)

I think there is still some misinterpretation of my comments, Rich.

 

I did not say >8352 must be cleared to zero every time. I meant to infer >8352 is not being set properly. Clearing it was appropriate for Michael's test, it is not appropriate if the sector number is greater than 65535 (>FFFF).

 

What I also said is that I do NOT see your code setting >8352 prior to the hard drive sector read. If your code doesn't set the value in FAC8, you have an unknown value passed to the device. Please identify where both 8350 and 8352 are being set by RXB.

 

Sector size is not an issue. ALL devices (floppy, RAMdisk, SCSI, IDE, HFDC, CF7) transfer 256 byte sectors, even if the device is formatted to 512 bytes per sector. The DSR handles splitting the sector if needed. You cannot change the size of the sector.

 

Michael's code is accessing the hard drive sectors using routine >20. It is not accessing a floppy. Where are you seeing the floppy access in his code?

Edited June 22, 2014 by InsaneMultitasker

[RXB]

I think there is still some misinterpretation of my comments, Rich.

 

I did not say >8352 must be cleared to zero every time. I meant to infer >8352 is not being set properly. Clearing it was appropriate for Michael's test, it is not appropriate if the sector number is greater than 65535 (>FFFF).

 

What I also said is that I do NOT see your code setting >8352 prior to the hard drive sector read. If your code doesn't set the value in FAC8, you have an unknown value passed to the device. Please identify where both 8350 and 8352 are being set by RXB.

 

Sector size is not an issue. ALL devices (floppy, RAMdisk, SCSI, IDE, HFDC, CF7) transfer 256 byte sectors, even if the device is formatted to 512 bytes per sector. The DSR handles splitting the sector if needed. You cannot change the size of the sector.

 

Michael's code is accessing the hard drive sectors using routine >20. It is not accessing a floppy. Where are you seeing the floppy access in his code?

Thanks for prompt reply.

Here is the source code to show that >8350 and >8352 are being properly set. Look at the previous Source I posted it is the same RXB SECTOR used for 2001 and 2012. (NO CHANGES IN 10 YEARS!)

<0780> D953 35,00,04 SECTOA MOVE 4,V@>03C0,@FAC6   * Get #
       D956 50,A3,C0
<0781> D959 8E,16           CZ   @DFLAG            * DSK?
<0782> D95B 59,60           BR   SECTOB            * No.
<0783> D95D BD,50,52        DST  @FAC8,@FAC6       * DISK

If Hard Drive it jumps past the DST @FAC8,@FAC6 and does not matter anyway as I have proved that SECTOR in RXB works just fine on FLOPPY DISK and only fails on Hard Disk.

If you go back up in the code you will see the values in >03CO are the String value of for Sector converted to hex for >8350 and >8352

 

Besides if your argument that I must clear >8352 was true then why does FLOPPY DISK work fine but HARD DISK fails? (As I fail to clear >8352?)

 

If >8352 is cleared for Hard Drive access then how would you read Sector 0 (zero) ever in 32 bit format as you just indicated that the maximum sectors are 65535 max? (thus 16 bit only?)

Are you guys saying the maximum size of any hard drive is only 65535 sectors and that this is 16 bit number and no 32 bit size Sectored drive exists?

 

Then explain to me why with zero changes to my code it worked fine for 10 years on a SCSI controllers? And Floppy Controllers?

My SCSI drives used way more then 65535 sectors and worked great?

Edited June 22, 2014 by RXB

[+InsaneMultitasker]

 

Thanks for prompt reply.

Here is the source code to show that >8350 and >8352 are being properly set. Look at the previous Source I posted it is the same RXB SECTOR used for 2001 and 2012. (NO CHANGES IN 10 YEARS!)

<0780> D953 35,00,04 SECTOA MOVE 4,V@>03C0,@FAC6   * Get #
       D956 50,A3,C0
<0781> D959 8E,16           CZ   @DFLAG            * DSK?
<0782> D95B 59,60           BR   SECTOB            * No.
<0783> D95D BD,50,52        DST  @FAC8,@FAC6       * DISK

If Hard Drive it jumps past the DST @FAC8,@FAC6 and does not matter anyway as I have proved that SECTOR in RXB works just fine on FLOPPY DISK and only fails on Hard Disk.

If you go back up in the code you will see the values in >03CO are the String value of for Sector converted to hex for >8350 and >8352

 

Besides if your argument that I must clear >8352 was true then why does FLOPPY DISK work fine but HARD DISK fails? (As I fail to clear >8352?)

 

If >8352 is cleared for Hard Drive access then how would you read Sector 0 (zero) ever in 32 bit format as you just indicated that the maximum sectors are 65535 max? (thus 16 bit only?)

Are you guys saying the maximum size of any hard drive is only 65535 sectors and that this is 16 bit number and no 32 bit size Sectored drive exists?

 

Then explain to me why with zero changes to my code it worked fine for 10 years on a SCSI controllers? And Floppy Controllers?

My SCSI drives used way more then 65535 sectors and worked great?

 

 

So then why did RXB set the value in 8352 to 03C2 here???

http://atariage.com/forums/topic/225612-setting-mess-using-qmc2/page-3?do=findComment&comment=3014282

 

1. 8352 is ignored for floppies. Your proof is limited to the fact 8350 is loaded with a sector number.

2. I already provided possible reasons for the failure. Sadly, my time machine prototype is not working today so I am unable to travel to 1994. For all I know, the earlier SCSI DSR sector number code was backwards and could explain what you are telling us.

3. Show me how RXB converts sector #70,000(decimal) into hex and what values you place into 8350 and 8352 in RXB. Walk me through your GPL code and the values that are computed. I don't thoroughly understand GPL.

[RXB]

I can confirm that CALL SECTOR("WDS1.",1,1,"0") leads to a File Error, but I do not know why this error occurs. There seems to be an access to the HD, but always to sector CHS=(0,0,0), regardless of the value in quotes. So either there is a problem with the parameter setup for the sector read subprogram, maybe due to an incompatibility between SCSI and HFDC, or actually an issue in MESS. As the hard disk is properly working (which somehow entails sector access), this may be not so easy to find out. I'll have to write a simple test program first, I suppose.

RXB uses >03CO as a buffer address in VDP to save the value of the 32 bit Sector to access.

If you look at the RXB source code VDP >03CO is a buffer to take the string and turn it from a string "00000000" into HEX >0000 >0000 and saves this at >03C0

 

If I had MG EXPLORER I could do like I did on my Real TI and Trouble shoot RXB to see what is going wrong.

 

How do I import my MG EXPLORER disk into MESS?

[RXB]

 

So then why did RXB set the value in 8352 to 03C2 here???

http://atariage.com/forums/topic/225612-setting-mess-using-qmc2/page-3?do=findComment&comment=3014282

 

1. 8352 is ignored for floppies. Your proof is limited to the fact 8350 is loaded with a sector number.

2. I already provided possible reasons for the failure. Sadly, my time machine prototype is not working today so I am unable to travel to 1994. For all I know, the earlier SCSI DSR sector number code was backwards and could explain what you are telling us.

3. Show me how RXB converts sector #70,000(decimal) into hex and what values you place into 8350 and 8352 in RXB. Walk me through your GPL code and the values that are computed. I don't thoroughly understand GPL.

String converted from a 16 character string to a Hex double word value.

<0723> D8B5 06,D1,0C        CALL STRGET            * SECTOR STRING FETCHED from XB
<0724> D8B8 8F,50           DCZ  @FAC6             * 0 string length?
<0725> D8BA 65,A2           BS   ERRBV             * ERROR BAD VALUE
<0726> D8BC 8E,16           CZ   @DFLAG            * DSK? Check if DISK or HARD FLAG set
<0727> D8BE 58,C6           BR   SECTO2            * No must be HARD so jump ahead to SECT02
<0728> D8C0 CB,50,00        DCHE 5,@FAC6           * String to long?
       D8C3 05
<0729> D8C4 65,A2           BS   ERRBV             * ERROR BAD VALUE
<0730> D8C6 CB,50,00 SECTO2 DCHE 9,@FAC6           * String to long HARD?
       D8C9 09
<0731> D8CA 65,A2           BS   ERRBV             * ERROR BAD VALUE
<0732> D8CC BD,0C,50        DST  @FAC6,@BYTES      * Save string length value.
<0733> D8CF A1,4E,50        DADD @FAC6,@FAC4       * Point past end of string.
<0734> D8D2 93,4E           DDEC @FAC4             * Offset to end of string.
<0735> D8D4 86,50           CLR  @FAC6             * Sector # buffer cleared
<0736> D8D6 35,00,04        MOVE 4,@FAC6,@FAC7     * Clear buffer with ripple so puts same value for 4 bytes
       D8D9 51,50
<0737> D8DB BF,5C,03        DST  >03C3,@ARG        * # number pointer at end of buffer in ARG
       D8DE C3
<0738> D8DF 86,A3,C0        CLR  V@>03C0           * Puts zero in >03C0
<0739> D8E2 35,00,04        MOVE 4,V@>03C0,V@>03C1 * Ripple value 4 bytes
       D8E5 A3,C1,A3
       D8E8 C0
<0740> D8E9 86,4A    SECTO3 CLR  @FAC              * Zero in FAC
<0741> D8EB BC,4A,B0 SECTO4 ST   V*FAC4,@FAC       * Get character and put in FAC
       D8EE 4E
<0742> D8EF CA,4A,47        CHE  71,@FAC           * G or higher?
<0743> D8F2 65,9A           BS   ERRBA             * ERROR BAD ARGUMENT
<0744> D8F4 CA,4A,41        CHE  65,@FAC           * A or higher?
<0745> D8F7 79,03           BS   SECTO5            * Yes go find HEX value
<0746> D8F9 CA,4A,3A        CHE  58,@FAC           * : or higher?
<0747> D8FC 65,9A           BS   ERRBA             * ERROR BAD ARGUMENT
<0748> D8FE CA,4A,30        CHE  48,@FAC           * 0 or higher?
<0749> D901 45,9A           BR   ERRBA             * ERROR BAD ARGUMENT
<0750> D903 A6,4A,30 SECTO5 SUB  48,@FAC           * - 0 (makes it a value from 0 to 9 in HEX)
<0751> D906 CA,4A,0A        CHE  10,@FAC           * 10 or higher?
<0752> D909 59,0E           BR   SECTO6            * No, must be ok so go save it.
<0753> D90B A6,4A,07        SUB  >07,@FAC          * - 7 (Must be A to F so -7 to make it HEX)
<0754> D90E BC,4C,4A SECTO6 ST   @FAC,@FAC2        * Save nibble.
<0755> D911 93,4E           DDEC @FAC4             * $ pointer - 1 (String Pointer move to the left 1 place in string)
<0756> D913 93,0C           DDEC @BYTES            * $ length - 1 (Number of bytes to do 1 less)
<0757> D915 59,1E           BR   SECTO7            * BYTES=0? No so go to SECTO7
<0758> D917 BC,B0,5C        ST   @FAC2,V*ARG       * Save # nibble in VDP at >03C3 first pass or >03C1 on second pass
       D91A 4C
<0759> D91B 05,D9,53        B    SECTOA            * End routine. (Obviously if BYTES is ZERO we are now done)
<0760> D91E BC,4A,B0 SECTO7 ST   V*FAC4,@FAC       * Get character and put in FAC
       D921 4E
<0761> D922 CA,4A,47        CHE  71,@FAC           * G or higher?

99/4 GPL-ASSEMBLER (Pass 3) correct                                   PAGE 0062 
EQUATES ALCS-359
<0762> D925 65,9A           BS   ERRBA             * ERROR BAD ARGUMENT
<0763> D927 CA,4A,41        CHE  65,@FAC           * A or higher?
<0764> D92A 79,36           BS   SECTO8            * Yes, so go to SECTO8
<0765> D92C CA,4A,3A        CHE  58,@FAC           * : or higher?
<0766> D92F 65,9A           BS   ERRBA             * ERROR BAD ARGUMENT
<0767> D931 CA,4A,30        CHE  48,@FAC           * 0 or higher? 
<0768> D934 45,9A           BR   ERRBA             * ERROR BAD ARGUMENT
<0769> D936 A6,4A,30 SECTO8 SUB  48,@FAC           * - 0 (makes it a value from 0 to 9 in HEX)
<0770> D939 CA,4A,0A        CHE  10,@FAC           * 10 or higher?
<0771> D93C 59,41           BR   SECTO9            * No, must be ok so go save it.
<0772> D93E A6,4A,07        SUB  >07,@FAC          * - 7 (Must be A to F so -7 to make it HEX)
<0773> D941 E2,4A,04 SECTO9 SLL  4,@FAC            * Swap nibbles. (Shift Left Logical 4 bits also fills empty new bits with zero)
<0774> D944 A0,4A,4C        ADD  @FAC2,@FAC        * Add old nibble. (Add old right nibble to new left nibble for new byte)
<0775> D947 BC,B0,5C        ST   @FAC,V*ARG        * Save # (Put byte in VDP >03C? range from >03C3 to >03C0)
       D94A 4A
<0776> D94B 93,5C           DDEC @ARG              * # pointer - 1 (Move left one Byte)
<0777> D94D 93,4E           DDEC @FAC4             * $ pointer - 1 (Move left one Character in string)
<0778> D94F 93,0C           DDEC @BYTES            * $ length - 1  (Number of bytes to do minus 1)
<0779> D951 58,E9           BR   SECTO3            * BYTES=0? No, goto SECTO3
<0780> D953 35,00,04 SECTOA MOVE 4,V@>03C0,@FAC6   * Get # by getting 4 byte HEX value and put those 4 bytes into FAC6

I added tons of comments to this and explained every single step of the conversion from String to HEX.

 

But you did not answer my previous question of why my code that worked for 10 years for everyone with no complaints does not work with MESS?

 

I can not find any way for >03C0 to be in >8352 after all the GPL code shows that before I access the DSR at all I moved the 4 bytes I just created from V@>03C0 into FAC6

I mean if this was a problem for DISK it would crash also as the wrong values would be in FAC6 and FAC8 then also?

After all when DISK it moves from FAC8 to FAC6

<0780> D953 35,00,04 SECTOA MOVE 4,V@>03C0,@FAC6   * Get #
       D956 50,A3,C0
<0781> D959 8E,16           CZ   @DFLAG            * DSK?
<0782> D95B 59,60           BR   SECTOB            * No.
<0783> D95D BD,50,52        DST  @FAC8,@FAC6       * DISK

If you find >03CO in >8352 how the heck did it get there?

And the above code just moved @FAC8 (>8352) to FAC6 (>8350) so why did the DISK Sector access work at all? (It should read >03C0 on DISK?)

 

No one else has EVER written GPL for Hard Drive SECTOR Access and it did work previously for years.

What makes you think MESS is so bullet proof?

 

I am suspecting a bad copy of RXB 2012 here. Will have to check byte by byte to see.

[+InsaneMultitasker]

If you find >03CO in >8352 how the heck did it get there?

And the above code just moved @FAC8 (>8352) to FAC6 (>8350) so why did the DISK Sector access work at all? (It should read >03C0 on DISK?)

 

 

I never said MESS is bullet proof.

 

If you want RXB to read sector 70,000 decimal, what values are in put into 8350 and 8352 based on your code? Second question: you just told me that DISK access moves FAC8 to FAC6. Why?