Programming challenge

[Gazoo]

Below is listed the code that is embedded in a TI Basic program to load an EA5 program, 'DSK1.GROMLOAD'.

The embedding process messes up scratchpad, so the areas that the disk controller uses need to be repaired.

The repair that makes the TI Disk Controller work is the code that is in the color red. Thank you Tursi.

The repair doesn't work with the Nano/CF7.

The challenge is to make the repair work with both the TI Disk Controller and the Nano/CF7 devices.

The winner of the challenge gets an 'Attaboy!' and a pat on the back.

 

Have at it.

 

Gazoo

 

 

 

DEF START Show where program starts.

AORG >3000

START B @START1 Go to actual start of program.

PAB DATA >0500,>0FF0,>0000,>2000 Data for PAB

BYTE >00

FILENM BYTE >0D Length byte, pathname.filename

TEXT 'DSK1.GROMLOAD '

VDPWA EQU >8C02 VDP WRITE address register

VDPRD EQU >8800 VDP READ DATA REGISTER

BUFFER EQU >0FC0

PABADR EQU >0F80

WR BSS >20 Save space for workspace.

START1 CLR @>837C

LWPI >83E0 Load workspace.

CLR R0

LI R1,>D237 37D2 swapped

MOVB R1,*R15

SWPB R1

MOVB R1,*R15 now it's in the right order

MOVB @>8800,R0 get byte

CI R0,>AA00 is it AA?

JEQ YAYSAV

LI R1,>37D8 37D8

YAYSAV DEC R1

MOV R1,@>8370 save value

LWPI WR Load workspace.

LI R0,>0000 Set VDP register 0.

BLWP @VWTR

LI R1,>E000

MOVB R1,@>83D4

LI R0,>01E0 Set VDP register 1.

BLWP @VWTR

LI R0,>0200 Set VDP register 2.

BLWP @VWTR

LI R0,>030E Set VDP register 3.

BLWP @VWTR

LI R0,>0401 Set VDP register 4.

BLWP @VWTR

LI R0,>0717 Set VDP register 7.

BLWP @VWTR

LI R0,>0380 Get ready to load color table.

LI R1,>1717 Set reg. 1 to color >17.

TABLE BLWP @VSBW Load 1 byte.

INC R0 Increment one byte.

CI R0,>03A0 Done yet?

JNE TABLE No, load another byte.

FILE1 LI R0,PABADR

LI R1,PAB

LI R2,26

BLWP @VMBW

LI R6,PABADR+9

MOV R6,@>8356

BLWP @DSRLNK

DATA 8

NOP

LI R0,>0FF6

LI R1,>A000

LI R2,>1FFA

BLWP @VMBR

NOP

B @>A000

***********************************************************

MOVBTS MOVB *R9+,*R10+

DEC R4

JGT MOVBTS

RT

***********************************************************

* UTILITIES ***********************************************************

SET DATA >2000

SAVE DATA 0

REGS BSS 32

EVEN

VMBW DATA REGSV,V1

REGSV DATA 0,0,0,>8C02

DATA >8C00,0,>8800,0

DATA >4000,>8000,0,0

DATA 0,0,0,0

V1 MOV R13,R7

MOV *R7+,R0

MOV *R7+,R1

MOV *R7+,R2

SWPB R0

MOVB R0,*R3

SWPB R0

SOC R8,R0

MOVB R0,*R3

NOP

V2 MOVB *R1+,*R4

DEC R2

JNE V2

RTWP

VSBW DATA REGSV,V3

V3 MOV R13,R7

MOV *R7+,R0

SWPB R0

MOVB R0,*R3

SWPB R0

SOC R8,R0

MOVB R0,*R3

NOP

MOVB *R7,*R4

RTWP

VWTR DATA REGSV,V4

V4 MOV *R13,R0

SOC R9,R0

SWPB R0

MOVB R0,*R3

SWPB R0

MOVB R0,*R3

RTWP

VSBR DATA REGSV,V5

V5 MOV R13,R7

MOV *R7+,R0

SWPB R0

MOVB R0,*R3

SWPB R0

MOVB R0,*R3

NOP

MOVB *R6,*R7

RTWP

VMBR DATA REGSV,V6

V6 MOV R13,R7

MOV *R7+,R0

MOV *R7+,R1

MOV *R7+,R2

SWPB R0

MOVB R0,*R3

SWPB R0

MOVB R0,*R3

V7 MOVB *R6,*R1+

DEC R2

JNE V7

RTWP

DSRLNK DATA REGSD,D1

REGSD DATA 0,0,0,0,0

DEVA DATA 0,0,0,0,0,0,0,0,0,0,0

DCRU DATA 0

DSENT DATA 0

DLEN DATA 0

DPAB DATA 0

DVERS DATA 0

DEV DATA 0,0,0,0

PERIOD TEXT '.'

HEXAA BYTE >AA

DFLAG DATA 0

D1 CLR @DFLAG

MOV *R14+,R5

SZCB @SET,R15

MOV @>8356,R0

MOV R0,R9

AI R9,-8

BLWP @VSBR

MOVB R1,R3

SRL R3,8

SETO R4

LI R2,DEV

D2 INC R0

INC R4

C R4,R3

JEQ D3

BLWP @VSBR

MOVB R1,*R2+

CB R1,@PERIOD

JNE D2

D3 MOV R4,R4

JEQ D88

CI R4,7

JGT D88

CLR @>83D0

MOV R4,@>8354

MOV R4,@DLEN

INC R4

A R4,@>8356

MOV @>8356,@DPAB

D4 LWPI >83E0

CLR R1

LI R12,>0F00

D5 MOV R12,R12

JEQ D55

SBZ 0

D55 AI R12,>0100

CLR @>83D0

CI R12,>2000

JEQ DX

MOV R12,@>83D0

SBO 0

LI R2,>4000

CB *R2,@HEXAA

JNE D5

A @DEVA,R2

JMP D66

D6 MOV @>83D2,R2

SBO 0

D66 MOV *R2,R2

JEQ D5

MOV R2,@>83D2

INCT R2

MOV *R2+,R9

MOVB @>8355,R5

JEQ D77

CB R5,*R2+

JNE D6

SRL R5,8

LI R6,DEV

D7 CB *R6+,*R2+

JNE D6

DEC R5

JNE D7

D77 INC R1

MOV R1,@DVERS

MOV R9,@DSENT

MOV R12,@DCRU

BL *R9

JMP D6

SBZ 0

LWPI REGSD

MOV R9,R0

BLWP @VSBR

SRL R1,13

JNE D9

RTWP

D8 LWPI REGSD

D88 CLR R1

D9 SWPB R1

MOVB R1,*R13

SOCB @SET,R15

RTWP

DX MOV @DFLAG,@DFLAG

JNE D8

SETO @DFLAG

LI R12,>0F00

JMP D5

KSCAN DATA KSCAN,KSCAN+4

MOV *R11,R12

LWPI >83E0

BL @>000E

LWPI KSCAN

MOV R12,*R11

RTWP

***********************************************************

END

 

[+InsaneMultitasker]

Quick observation that we have discussed in past threads:

 

Nanopeb/cf7 require an additional 8 bytes reserved at the top of VDP. I'm not sure if testing 37d2 for 0xaa is going to do any good with the cf7/nanopeb. Change 37d8 to 37d0 or for a more definitive, nanopeb/cf7 only test, hardcode 8370 to 37cf. Also be sure GPLWS R15 is set properly.

Edited June 6, 2015 by InsaneMultitasker

[RXB]

Why not use the GPLDSRLNK?

 

It works with all devices of any kind?

 

Also you could run the ROM 0 routines and this would make it much smaller?

Edited June 6, 2015 by RXB

[+OLD CS1]

I will go one further: if anyone fixes this, I will wear my "Batman" thermals during the 2015 bar crawl.

[+Lee Stewart]

Gazoo/Tursi...

1. I was not aware that the 6-byte area below the disk buffer area in VRAM could be relied on not to change once the disk DSR relinquishes power-up control.. It is below the highest available VRAM address stored in RAM >8370. This is irrelevant due a misunderstanding on my part and bad docs from TI’s SOFTWARE SPECIFICATIONS FOR THE 99/4 DISK PERIPHERAL (see later posts).
2. If more room in VRAM is needed by the file being loaded, is it possible to change to CALL FILES(2) before the embedding process? That would make high VRAM >39DD (>39D5 for nanoPEB/CF7).
3. Can >8370 in RAM be sampled by the embedding/embedded code before it is destroyed?

...lee

Edited June 8, 2015 by Lee Stewart

[Gazoo]

Gazoo/Tursi...

1. I was not aware that the 6-byte area below the disk buffer area in VRAM could be relied on not to change once the disk DSR relinquishes power-up control.. It is below the highest available VRAM address stored in RAM >8370.
2. If more room in VRAM is needed by the file being loaded, is it possible to change to CALL FILES(2) before the embedding process? That would make high VRAM >39DD (>39D5 for nanoPEB/CF7).
3. Can >8370 in RAM be sampled by the embedding/embedded code before it is destroyed?

...lee

 

I can't answer any of these questions. The Playground embedding process is still a mystery to me. I generally take the image that I end up with from my code and paste it in the appropriate place in the original Basic program image that Senior Falcon created. So I'm assuming that the patch is going to have to test for both devices, determine which one is in use, and then place the correct value in >8370.

 

Gazoo

[+InsaneMultitasker]

 

So I'm assuming that the patch is going to have to test for both devices, determine which one is in use, and then place the correct value in >8370.

 

Gazoo

Have you tried hard-coding the value in 8370 to 8 fewer bytes, i.e., 37cf as suggested?

 

There is no rule that says you cannot reserve more VDP beyond what the TI Controller requests, that's what 8370 is there for. If a loaded program tests 8370 per specifications, it would have 8 bytes less VDP to use; if a program ignores 8370, it won't matter anyway. If you don't want to hardcode the value, the "easy" thing to do is change the playground or related program to stuff 8370 somewhere for your later retrieval during the jump into the loader.

[Gazoo]

Have you tried hard-coding the value in 8370 to 8 fewer bytes, i.e., 37cf as suggested?

 

There is no rule that says you cannot reserve more VDP beyond what the TI Controller requests, that's what 8370 is there for. If a loaded program tests 8370 per specifications, it would have 8 bytes less VDP to use; if a program ignores 8370, it won't matter anyway. If you don't want to hardcode the value, the "easy" thing to do is change the playground or related program to stuff 8370 somewhere for your later retrieval during the jump into the loader.

 

Well, thats the thing, "I" can't try it because I don't have a CF/Nano. That's why I posted the code so someone with one of those devices could try it. Doesn't the >AA and the next few bytes have to be in VDP where the pointer points to?

 

Gazoo

[+Lee Stewart]

 

... Doesn't the >AA and the next few bytes have to be in VDP where the pointer points to?

 

Gazoo

 

Nope—not to my knowledge. That >AA can only be guaranteed to be there immediately after the disk DSR relinquishes control at power-up. The fact that >8370 gives the highest available VDP address as immediately below the first File Control Block and above the address containing >AA, means it can be stepped on at any time. That byte is, in fact, preserved; but, it is actually above the value stored in >8370 (see later posts).

 

...lee

Edited June 7, 2015 by Lee Stewart

[+InsaneMultitasker]

 

Well, thats the thing, "I" can't try it because I don't have a CF/Nano. That's why I posted the code so someone with one of those devices could try it. Doesn't the >AA and the next few bytes have to be in VDP where the pointer points to?

 

Gazoo

Ah, ok. You didn't make CF/nano ownership clear from your original post.

 

As for the pointer I agree with Lee. However, programmers and DSR routines might still tie the two together, making it an unofficial "standard". There is probably merit to investigating further.

 

This reminds me - if the validation code is assumed to be pointed to by 8370, then why is the test for "AA" being done on 0x37D2? Seems this will always fail, setting 8370 via the "LI" statement.

[+Lee Stewart]

...

This reminds me - if the validation code is assumed to be pointed to by 8370, then why is the test for "AA" being done on 0x37D2? Seems this will always fail, setting 8370 via the "LI" statement.

 

>37D2 is part of the 6-byte “additional information area” (AIA) below the VRAM disk buffer area—see attached GIFs from TI’s SOFTWARE SPECIFICATIONS FOR THE 99/4 DISK PERIPHERAL. That AIA is all in or below the highest available VRAM address maintained in >8370 by the disk DSR. If you put some lower value in >8370, it is fine until DSR subprogram >16 (CALL FILES(n) in TI Basic) is executed will change the value at >8370. Subprogram >16 will set it to the new value to preserve the file buffer area at the top of VRAM. This is why I think that >8370 absolutely must be saved before the Playground code messes with it. The Playground manual says that there is a 114-byte area in Scracthpad RAM available for program paging. I think this should be limited to 112 bytes to preserve >8370 until it can be dealt with by the embedded code.

 

 

[Edit: Figure 7.1 above actually has the VDP Stack Space wrong—it is 252 bytes, not 256. This means that the Validity Code on up are all in “protected” space.]

 

...lee

Edited June 7, 2015 by Lee Stewart

[Gazoo]

So if I understand correctly, I can replace the entire red block of code with:

 

LI R1,>37CF

MOV R1,@>8370 save value

...and it should work correctly for both devices?

Gazoo

[+InsaneMultitasker]

 

So if I understand correctly, I can replace the entire red block of code with:

 

LI R1,>37CF

MOV R1,@>8370 save value

...and it should work correctly for both devices?

Gazoo

 

 

Lee and I are testing some things with different controllers.

 

The code above would be a good test to verify the loader works with CF7/nanopeb but not a full solution. We both have adjourned our activities for the day.

[Gazoo]

Finally letting all this sink in...

 

It seems prudent, then, to look around in upper VDP for the >AA, then set >8370 according to which device puts it at the found memory location.

All would seem to be needed is a list of where the various devices put the >AA, or am I just talking to Rod Serling in a different place?

 

Gazoo

[Opry99er]

off topic, but Night Gallery was in MANY ways superior to The Twilight Zone.

 

Carry on....

[+InsaneMultitasker]

Finally letting all this sink in...

 

It seems prudent, then, to look around in upper VDP for the >AA, then set >8370 according to which device puts it at the found memory location.

All would seem to be needed is a list of where the various devices put the >AA, or am I just talking to Rod Serling in a different place?

 

Gazoo

 

Yep. Maybe limit this to a quick search of VDP from 0x37D0 to 0x37D8. Take the address of the first ">AA" found, subtract one, and stuff into 0x8370. Compare to known values for extra protection if desired.

 

Without going into full details that Lee and I were discussing here are the basic findings so far:

 

1. Lee verified that his BwG controller reserves 2 bytes of VDP at 0xfffe-0xffff. The ">AA" is at location 0x37d6.

2. The CF7/nanopeb devices reserve 8 bytes of VDP from 0xfff8-0xffff. ">AA03" is located at 0x37d0. (This usage doesn't conform to the full 5-byte validation header normally constructed by the floppy controllers.)

3. CorComp FDC, Myarc FDC, Myarc HFDC (at 1100 only), and TI controller locate ">AA" at 0x37d8.

4. The Myarc HFDC does NOT construct a VDP header nor change 0x8370 if it is configured to any CRU besides 0x1100.

5. WHT SCSI controllers do not manipulate the pointer.

6. Horizon RAMdisk ROS expects a floppy DSR to reserve VDP RAM, as it stuffs some things there. This leads to interesting problems in XB and BASIC since the programs grow downward in VDP from the highest available point. Using a Horizon RAMdisk without a floppy controller will lead to corruption in memory and during save operations.

[+OLD CS1]

off topic, but Night Gallery was in MANY ways superior to The Twilight Zone.

 

Carry on....

 

Eh, I do like both but prefer Twilight Zone. My absolute favorite episode is "The Obsolete Man."

[senior_falcon]

There is no way to preserve the contents of >8370 when you load a program using playground. The loader uses a bug discovered by James Abatiello. When you OPEN #1:"DSK1.TEST" TI BASIC wants to load the string into scratchpad RAM starting at >834A. But it thoughtfully tries to keep you from loading too long a string which would overwrite stuff needed by the BASIC interpreter. So if the string is greater than around 10 (I forgot the actual number) it will give an error message. Here's the bug: if the string is 128 bytes or longer then it is less than 0, hence less than 10, and BASIC will dutifully load it into scratchpad ram starting at >834A. If the string contains assembly code you can sneak it into scratchpad ram without BASIC knowing about it. But you have to trash everything from >834A to >83CA (at least) just to get the code into scratchpad ram. Playground then plugs an address into the interrupt routine which starts up the loader which then takes control of the computer.

Edited June 7, 2015 by senior_falcon

[Gazoo]

 

Eh, I do like both but prefer Twilight Zone. My absolute favorite episode is "The Obsolete Man."

 

None of them actually compare to the first episode of The Outer Limits, 'Galaxy Being'.

My favorite scifi episode of all time.

 

Gaz

[Gazoo]

There is no way to preserve the contents of >8370 when you load a program using playground. The loader uses a bug discovered by James Abatiello. When you OPEN #1:"DSK1.TEST" TI BASIC wants to load the string into scratchpad RAM starting at >834A. But it thoughtfully tries to keep you from loading too long a string which would overwrite stuff needed by the BASIC interpreter. So if the string is greater than around 10 (I forgot the actual number) it will give an error message. Here's the bug: if the string is 128 bytes or longer then it is less than 0, hence less than 10, and BASIC will dutifully load it into scratchpad ram starting at >834A. If the string contains assembly code you can sneak it into scratchpad ram without BASIC knowing about it. But you have to trash everything from >834A to >83CA (at least) just to get the code into scratchpad ram. Playground then plugs an address into the interrupt routine which starts up the loader which then takes control of the computer.

 

It's mind boggling that someone actually discovered something like that.

 

--- deep bow ---

 

Gazoo

[Gazoo]

Just in case anyone doesn't see the relevance of this process, the idea is to get an EA5 program to load from TI BASIC from any device.

 

Once that works, then all the imagineers can devise a universal EA5 loader from TI BASIC. Cool, Baby!

 

Gazzzooooo

[+Schmitzi]

Cool. Do I get the 'Attaboy!' now ?

 

[Gazoo]

Cool. Do I get the 'Attaboy!' now ?

 

 

Yes, immediately after you post the working code.

 

 

GughZoo

[+Lee Stewart]

There is no way to preserve the contents of >8370 when you load a program using playground. The loader uses a bug discovered by James Abatiello. When you OPEN #1:"DSK1.TEST" TI BASIC wants to load the string into scratchpad RAM starting at >834A. But it thoughtfully tries to keep you from loading too long a string which would overwrite stuff needed by the BASIC interpreter. So if the string is greater than around 10 (I forgot the actual number) it will give an error message. Here's the bug: if the string is 128 bytes or longer then it is less than 0, hence less than 10, and BASIC will dutifully load it into scratchpad ram starting at >834A. If the string contains assembly code you can sneak it into scratchpad ram without BASIC knowing about it. But you have to trash everything from >834A to >83CA (at least) just to get the code into scratchpad ram. Playground then plugs an address into the interrupt routine which starts up the loader which then takes control of the computer.

 

The problem with this is that most (all) of the disk DSRs that rely on upper VRAM buffer space expect >8370 to have the correct “highest available VDP memory address”. If you change it to something else, the DSR will hang. I have changed the value at >8370 to something other than the value it had and the DSR would no longer cooperate. This was on the real iron with both the CorComp and the nanoPEB disk controllers. If Playground will not cooperate, it cannot be used for disk I/O without presuming the correct value for a given controller. Even if the correct value is presumed, but Playground trashes the relevant 5 bytes below the disk buffers (possible with CF7/nanoPEB controllers), they would also need to be restored to proper values.

 

If we can limit the loader to systems that use only CorComp FDC, Myarc FDC, Myarc HFDC (at 1100 only), TI and CF7/nanoPEB controllers, then we only need to check >3FF8 for >AA03 to determine that we are dealing with a CF7/nanoPEB. If it is a CF7/nanoPEB, we need to restore >8370 with >37CF and all the others with >37D7. It would then be advisable to restore the 5 bytes of VRAM above that value with >AA3FFF1103. If we wish to include the BwG controller in the mix, we need to also check >3FFF for >AA and then restore >8370 to >37D5 and the relevant 5 bytes above to >AA3FFD1103. That will get most disk controllers except for the ones that Tim mentioned in post #16 that are not included here.

 

Because there is a remote chance that DSK3 (logged at >3FFE – >3FFF) for a CF7/nanoPEB points to Vol# 170 (>AA) or any Vol# ending in >AA (426, 682, 938, ...), the test for the two odd controllers (CF7/nanoPEB and BwG) should first test for the CF7/nanoPEB and then the BwG controller.

 

...lee

[+Ksarul]

The only other controllers that aren't included in the list are the ones from Percom Data (TX99) and Atronic (a CorComp workalike, but it might not use the same locations as the TI controller).