Jump to content
Gazoo

Programming challenge

Recommended Posts

Even if the correct value is presumed, but Playground trashes the relevant 5 bytes below the disk buffers (possible with CF&/nanoPEB controllers), they would also need to be restored to proper values.

 

Assuming these controllers can load a BASIC program (a safe assumption!) there shouldn't be any problem with that. The loader is a BASIC program and the only bytes that it changes are in the scratchpad. One possible way to restore >8370 would be to peek the value at that address using e/a or xb. That could be added to the BASIC loader and the information passed by putting it on the screen with HCHAR, then the loader reads it so it knows what the value should be. Not completely automatic, but it should be workable - you'd only have to do it once. Another possibility is that there is a CALL FILES subprogram in the DSR. That should set everything up correctly.

Share this post


Link to post
Share on other sites

 

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.

 

 

 

 

 

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.

 

 

 

There seems to be confusion on where to check for the >AA.

 

For the BWG, should v>37D6 (Insane) or v>3FFF (Lee) be checked?

For the CF/Nano, should v>37D0 (Insane) or v>3FF8 (Lee) be checked?

 

I've got code that should work, just need to plug in the proper 2 values.

 

Gazoo

Edited by Gazoo

Share this post


Link to post
Share on other sites

Assuming these controllers can load a BASIC program (a safe assumption!) there shouldn't be any problem with that. The loader is a BASIC program and the only bytes that it changes are in the scratchpad. One possible way to restore >8370 would be to peek the value at that address using e/a or xb. That could be added to the BASIC loader and the information passed by putting it on the screen with HCHAR, then the loader reads it so it knows what the value should be. Not completely automatic, but it should be workable - you'd only have to do it once. Another possibility is that there is a CALL FILES subprogram in the DSR. That should set everything up correctly.

 

I changed >8370 on the real iron with CorComp and nanoPEB controllers and MESS with a BwG controller. Then I tried the equivalent of TI Basic's CALL FILES(3) (I am using fbForth 2.0 for all of these operations) in an attempt to let the DSRs reset >8370. No Dice. If >8370 has the wrong information, all three DSRs hang. The only way I see to get around divining the correct value for >8370 and the values in the lowest 5 bytes of DSR-reserved VRAM, is to set >8370 to >3FFF and invoke the DSR's power-up routine—I do not know how to do that.

 

...lee

Share this post


Link to post
Share on other sites

 

 

 

There seems to be confusion on where to check for the >AA.

 

For the BWG, should v>37D6 (Insane) or v>3FFF (Lee) be checked?

For the CF/Nano, should v>37D0 (Insane) or v>3FF8 (Lee) be checked?

 

I've got code that should work, just need to plug in the proper 2 values.

 

Gazoo

 

There is no confusion. Tim's checks are for what should be in the lowest byte of the DSR-reserved VRAM space (true for all disk DSRs) if that part of VRAM has not been trashed. My checks at high VRAM space are for what should be there for the two controllers you mentioned, which will determine which, if any, of those two controllers is present. Most (all?) other controllers will not have >AA at the top of VRAM. Their top of VRAM will be the filename-comparison buffer.

 

...lee

Share this post


Link to post
Share on other sites

I should add to my last post that for the two controllers mentioned (CF7/nanoPEB and BwG), the >AA value is actually in two places. For a 3-file max, CF7/nanoPEB should have it at >37D0 and >3FF8; BwG should have it at >37D6 and >3FFF. The checks at the high location are to determine where the >AA byte should be at the other end of the DSR-reserved space: >37D0, >37D6 or >37D8.

 

...lee

Share this post


Link to post
Share on other sites

060715XB27.dsk

 

This version of BASICLOAD should work with all controllers, except maybe the 2 odd ones Ksarul mentioned. That is, if I understood the info provided. :) Tested so far with TI Controller.

 

Gazoo

 

The current source code is below:

 

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 '

EVEN

VDPWA EQU >8C02 VDP WRITE address register

VDPRD EQU >8800 VDP READ DATA REGISTER

BUFFER EQU >0FC0

PABADR EQU >0F80

CFNANO DATA >AA3F,>FF11,>0300

BWG DATA >AA3F,>FD11,>0300

CHECK DATA >0000

WR BSS >20 Save space for workspace.

START1 LWPI WR Load workspace.

CLR @>837C

LI R0,>3FF8 Get word at v>3FF8

LI R1,CHECK

LI R2,>0002

BLWP @VMBR

MOV @CHECK,R1

CI R1,>AA03 Check for CFNANO

JNE NEXT not found

LI R1,>37CF Restore highest available VDP

MOV R1,@>8370

LI R0,>37D0 Restore additional data

LI R1,CFNANO

LI R2,>0005

BLWP @VMBW

B @MOVEON Move on

NEXT LI R0,>3FFF Get byte at v>3FFF

LI R1,CHECK

BLWP @VSBR

CLR R1

MOVB @CHECK,R1

CI R1,>AA00 Check for BWG

JNE NEXT1 not found

LI R1,>37D5 Restore highest available VDP

MOV R1,@>8370

LI R0,>37D6 Restore additional data

LI R1,BWG

LI R2,>0005

BLWP @VMBW

B @MOVEON Move on

NEXT1 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

MOVEON 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 Set up PAB

LI R1,PAB

LI R2,26

BLWP @VMBW

LI R6,PABADR+9

MOV R6,@>8356

BLWP @DSRLNK Load the program

DATA 8

NOP

LI R0,>0FF6 Move the program to Ram

LI R1,>A000

LI R2,>1FFA

BLWP @VMBR

NOP

B @>A000 Execute the program

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

* 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

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

END

 

Share this post


Link to post
Share on other sites

attachicon.gif060715XB27.dsk

 

This version of BASICLOAD should work with all controllers, except maybe the 2 odd ones Ksarul mentioned. That is, if I understood the info provided. :) Tested so far with TI Controller.

 

Gazoo

 

The current source code is below:

 

BLWP @VMBW

B @MOVEON Move on

NEXT1 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

 

Looking good, but the line in red above still needs to be fixed. The test is incorrectly failing for the TI controller with potential for a false positive.

Share this post


Link to post
Share on other sites

...

This version of BASICLOAD should work with all controllers, except maybe the 2 odd ones Ksarul mentioned. That is, if I understood the info provided. :) Tested so far with TI Controller.

 

Gazoo

 

The current source code is below:

...

 

Damn! You beat me to it. I was almost done coding the changes.

 

I still do not understand the code between NEXT1 and MOVEON. I do not understand the switch to GPL workspace and the checking of the byte at >37D2. I would change that code to

 

NEXT1 LI R0,>37D8 Restore additional data for other DSRs
LI R1,CFNANO same data as CF7/nano
LI R2,>0005
BLWP @VMBW
LI R1,>37D7 >37D7 = highest available VRAM
MOV R1,@>8370 save value
MOVEON ...

...lee

Share this post


Link to post
Share on other sites

 

Damn! You beat me to it. I was almost done coding the changes.

 

I still do not understand the code between NEXT1 and MOVEON. I do not understand the switch to GPL workspace and the checking of the byte at >37D2. I would change that code to

 

Changing the workspace to GPLWS (0x83E0) is only necessary to utilize R15 as VDPWA. (The TI Controller, for example, uses this value HEAVILY, which is why I mentioned validating it was intact earlier in this thread).

 

The rest of the code sets the VDP write address (LSByte first) then reads the value and compares to the validation code 0xAA. I'm guessing the value 0xD237 was a typo as the value should be 0xD837.

Share this post


Link to post
Share on other sites

 

Changing the workspace to GPLWS (0x83E0) is only necessary to utilize R15 as VDPWA. (The TI Controller, for example, uses this value HEAVILY, which is why I mentioned validating it was intact earlier in this thread).

 

The rest of the code sets the VDP write address (LSByte first) then reads the value and compares to the validation code 0xAA. I'm guessing the value 0xD237 was a typo as the value should be 0xD837.

 

Thanks. Then my code should work—and, I do think it is just as important to restore the bottom 5 bytes of DSR-reserved VRAM for the controllers starting at >37D8 as for the other two.

 

...lee

Share this post


Link to post
Share on other sites

Another possibility is that there is a CALL FILES subprogram in the DSR. That should set everything up correctly.

 

I was just thinking this while reading everything -- some way to "ask" the DSR to correct everything as if at power-up.

Share this post


Link to post
Share on other sites

 

Thanks. Then my code should work—and, I do think it is just as important to restore the bottom 5 bytes of DSR-reserved VRAM for the controllers starting at >37D8 as for the other two.

 

...lee

yep. To be honest, I still don't see much value in restoring the VDP header, since we are already relying upon it to be present for the test to succeed, i.e., if the header is destroyed, we'll never find >AA nor can we call the device. The important thing is whether or not 8370 can be set properly to match the header which, presumably, the playground is not touching.

 

Share this post


Link to post
Share on other sites

yep. To be honest, I still don't see much value in restoring the VDP header, since we are already relying upon it to be present for the test to succeed, i.e., if the header is destroyed, we'll never find >AA nor can we call the device. The important thing is whether or not 8370 can be set properly to match the header which, presumably, the playground is not touching.

 

 

It looks as though the loader might step on that part of VRAM (the lower part), so, even if >8370 is properly set, it still will not work if the DSR cannot find the validation byte or its CRU ID. The only checking that is necessary, IMHO, is the >AA byte in high VRAM to see whether the controller is a CF7/nanoPEB or a BwG. Otherwise, we just presume it is a “normal” controller with the low end of VRAM at >37D8, never checking the validation byte, but “restoring” the critical 5 bytes at the bottom.

 

...lee

Share this post


Link to post
Share on other sites

 

It looks as though the loader might step on that part of VRAM (the lower part), so, even if >8370 is properly set, it still will not work if the DSR cannot find the validation byte or its CRU ID. The only checking that is necessary, IMHO, is the >AA byte in high VRAM to see whether the controller is a CF7/nanoPEB or a BwG. Otherwise, we just presume it is a “normal” controller with the low end of VRAM at >37D8, never checking the validation byte, but “restoring” the critical 5 bytes at the bottom.

 

...lee

Could you point out there the loader might step on VRAM and where? I'm not seeing it...

Share this post


Link to post
Share on other sites

Neither of the 2 versions that check for the TI controller as the 3rd step work. :(

 

Would it still work properly if the TI controller was checked for as the first step?

 

Gazoo

Share this post


Link to post
Share on other sites

060715XB27.dsk

 

I got it to work, don't know what happened first time around. This works ok with the TI controller, could someone please check the other devices?

 

Gazoo

 

Source:

 

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 '
EVEN
VDPWA EQU >8C02 VDP WRITE address register
VDPRD EQU >8800 VDP READ DATA REGISTER
BUFFER EQU >0FC0
PABADR EQU >0F80
CFNANO DATA >AA3F,>FF11,>0300
BWG DATA >AA3F,>FD11,>0300
CHECK DATA >0000
WR BSS >20 Save space for workspace.
START1 LWPI WR Load workspace.
CLR @>837C
LI R0,>3FF8 Get word at v>3FF8
LI R1,CHECK
LI R2,>0002
BLWP @VMBR
MOV @CHECK,R1
CI R1,>AA03 Check for CFNANO
JNE NEXT not found
LI R1,>37CF Restore highest available VDP
MOV R1,@>8370
LI R0,>37D0 Restore additional data
LI R1,CFNANO
LI R2,>0005
BLWP @VMBW
B @MOVEON Move on
NEXT LI R0,>3FFF Get byte at v>3FFF
LI R1,CHECK
BLWP @VSBR
CLR R1
MOVB @CHECK,R1
CI R1,>AA00 Check for BWG
JNE NEXT1 not found
LI R1,>37D5 Restore highest available VDP
MOV R1,@>8370
LI R0,>37D6 Restore additional data
LI R1,BWG
LI R2,>0005
BLWP @VMBW
B @MOVEON Move on
NEXT1 LI R0,>37D8 Restore additional data for other DSRs
LI R1,CFNANO same data as CF7/nano
LI R2,>0005
BLWP @VMBW
LI R1,>37D7 >37D7 = highest available VRAM
MOV R1,@>8370 save value
MOVEON 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 Set up PAB
LI R1,PAB
LI R2,26
BLWP @VMBW
LI R6,PABADR+9
MOV R6,@>8356
BLWP @DSRLNK Load the program
DATA 8
NOP
LI R0,>0FF6 Move the program to Ram
LI R1,>A000
LI R2,>1FFA
BLWP @VMBR
NOP
B @>A000 Execute the program
***********************************************************
* 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
***********************************************************
END

Share this post


Link to post
Share on other sites

It's been reported that the BWG code works. Thanks Atrax!

 

I was able to verify that it works with a Myarc FDC with 80 track eprom.

 

Gazoo

Share this post


Link to post
Share on other sites

It's been reported that the BWG code works. Thanks Atrax!

 

I was able to verify that it works with a Myarc FDC with 80 track eprom.

 

Gazoo

 

I will check my nanoPEB tomorrow.

 

...lee

Share this post


Link to post
Share on other sites

Could you point out there the loader might step on VRAM and where? I'm not seeing it...

 

I got it from these lines of Harry’s post #48 of his “Playground” thread:

SAVE this program as DM1000BX, then look into VDP with the classic99 debugger.  "STARTBUFFER" began at >3066 in VDP ram.
The second program below will copy >0772 bytes from CPU ram starting at >3000 and put them into VDP ram starting at >0366, then return to BASIC.  Save and assemble this.

I may be misreading the above or it may not be relevant to BASICLOAD; but, if it puts the code destined for RAM >3000 in VRAM at >3066 and it's >772 bytes long, it will just fill the top of available VRAM, stopping just short of >37D8, but definitely clobbering all of the CF7/nanoPEB’s lower 5 bytes and the validation code of the BwG controller. I just figured that, if it got any bigger with our mods, that all of that area for any controller gets clobbered. Like I said, I may be misunderstanding exactly what is going on with the embedding process.

 

...lee

Share this post


Link to post
Share on other sites

 

I got it from these lines of Harry’s post #48 of his “Playground” thread:

SAVE this program as DM1000BX, then look into VDP with the classic99 debugger.  "STARTBUFFER" began at >3066 in VDP ram.
The second program below will copy >0772 bytes from CPU ram starting at >3000 and put them into VDP ram starting at >0366, then return to BASIC.  Save and assemble this.

I may be misreading the above or it may not be relevant to BASICLOAD; but, if it puts the code destined for RAM >3000 in VRAM at >3066 and it's >772 bytes long, it will just fill the top of available VRAM, stopping just short of >37D8, but definitely clobbering all of the CF7/nanoPEB’s lower 5 bytes and the validation code of the BwG controller. I just figured that, if it got any bigger with our mods, that all of that area for any controller gets clobbered. Like I said, I may be misunderstanding exactly what is going on with the embedding process.

 

...lee

 

The first time I read the thread, I thought these steps were only needed to generate the files. Of course, the clobber would then happen at this stage and the nano/BwG would be unable to save the program to disk.

 

I wonder if this can be (has been?) modified to respect the CF7/nanopeb device VPD usage. Definitely a good question for Gazoo and/or Senior Falcon. ;)

 

The VDP information we've all been poking at would be good to consolidate and save somewhere like ninerpedia. This area of VDP is most challenging :)

Share this post


Link to post
Share on other sites

 

The first time I read the thread, I thought these steps were only needed to generate the files. Of course, the clobber would then happen at this stage and the nano/BwG would be unable to save the program to disk.

 

I wonder if this can be (has been?) modified to respect the CF7/nanopeb device VPD usage. Definitely a good question for Gazoo and/or Senior Falcon. ;)

 

The VDP information we've all been poking at would be good to consolidate and save somewhere like ninerpedia. This area of VDP is most challenging :)

 

Agreed—good question and suggestion! :thumbsup: :thumbsup: :thumbsup:

 

...lee

Share this post


Link to post
Share on other sites

 

...

I got it to work, don't know what happened first time around. This works ok with the TI controller, could someone please check the other devices?

 

Gazoo

 

...

 

Woohoo! BASICLOAD works with my nanoPEB! :-o

 

I still get the red FCTN+6 screen; but, everything I have checked so far works. The only extra step for me was to copy the files from 060715.DSK to a 1600-sector, CF7+ image of the same name via TI99Dir. I would not think that should matter.

 

...lee

Share this post


Link to post
Share on other sites

Would BASICLOAD load any EA5 file as long as the length byte and pathname were correct?

 

Looks like it should. You could probably make the program a general-purpose EA5 loader without a lot of work! :grin:

 

...lee

Share this post


Link to post
Share on other sites

 

I got it from these lines of Harry’s post #48 of his “Playground” thread:


SAVE this program as DM1000BX, then look into VDP with the classic99 debugger.  "STARTBUFFER" began at >3066 in VDP ram.
The second program below will copy >0772 bytes from CPU ram starting at >3000 and put them into VDP ram starting at >0366, then return to BASIC.  Save and assemble this.

I may be misreading the above or it may not be relevant to BASICLOAD; but, if it puts the code destined for RAM >3000 in VRAM at >3066 and it's >772 bytes long, it will just fill the top of available VRAM, stopping just short of >37D8, but definitely clobbering all of the CF7/nanoPEB’s lower 5 bytes and the validation code of the BwG controller. I just figured that, if it got any bigger with our mods, that all of that area for any controller gets clobbered. Like I said, I may be misunderstanding exactly what is going on with the embedding process.

 

...lee

I have added some edits to post #48 mentioned above which should help clarify things. These are highlighted in blue. Basically follow the recipe in that post. Since you are making a BASIC program it should work fine without modifying VEP ram that you care about. The CF7 should take care of the extra 5 bytes automatically. Naturally, if the loader is a different length than the one in post #48 then you have to modify the programs to embed a buffer that is the right length and move the right number of bytes into the buffer.

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.
Note: Your post will require moderator approval before it will be visible.

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