function DSRLNK error... someone can help ?

[up.n.down]

Hmm... looks like the code us missing somewhere. Dunno. One for the experts I think. Anyone? Is SAVE level 3 operation? I'm a newbie at this disk io stuff.

I'd wager the problem is with the workspace (or lack thereof). Recommend you set up your environment and shut down the interrupts, ie. If the program is called from the GPLWS and DSRLNK uses that same workspace, you end up with a mess on your hands....

 

I did! As I wrote, I testes Mark's code, than added my own workspace and disabled INTs (LIMI 0). The only difference from what you suggest is that i returned with RT (after restoring R11) but that's should not be the problem, as the system seems to be stuck in DSRLNK call :'(

 

 

I would also adjust the buffer start address from 0x1800 to 0x1200. Otherwise, you are mucking around with VDP space used by some of the disk controllers. For a good overview of the space, check out this doc pages 10 and 11 in particular.

ftp://whtech.com/magazines/smartprogrammer/sp8405.pdf

 

Interesting. I will fully read and try tonight. Isn't it just for XB?

 

Ciao

Ugo

[Willsy]

I'd wager the problem is with the workspace (or lack thereof). Recommend you set up your environment and shut down the interrupts, ie. If the program is called from the GPLWS and DSRLNK uses that same workspace, you end up with a mess on your hands....

 

MYWS BSS >20
START LWPI MYWS
LIMI 0
continue code

Try returning with a BLWP @0  

 

I would also adjust the buffer start address from 0x1800 to 0x1200. Otherwise, you are mucking around with VDP space used by some of the disk controllers. For a good overview of the space, check out this doc pages 10 and 11 in particular.

ftp://whtech.com/magazines/smartprogrammer/sp8405.pdf

 

I'll see your wager, and raise you..... A bucket and a packet of toenail clippings!

 

I'm 90% sure that when you launch a program via ED/AS #3 that the workspace is set up for somewhere in the >2000 area. I've been looking for the reference in the ED/AS manual, but, as usual can't find it!

 

However, the classic99 debugger can tell me...

 

<boots up classic99>

 

Okay, so, the program as written is relocatable, but checking the REF/DEF table at the end of the 8K reveals that it gets loaded at >A018... So, bang in a breakpoint at >A018 and launch the sucker...

 

Dun dun duuuuuuuuh...

 

So, the ED/AS sets up the workspace as >20BA, so we can discount that one. Now that I know that the WS is at >20BA I can search the ED/AS PDF file and guess what? It's on page 246

 

Your point about the location of the 8K buffer in VDP is a good one though... I set it at >1800. Hmmmm.... >1800 + >2000 = >3800. Hmmm... That doesn't look good. IIRC the disk controller uses some VDP at >37D8 and we've just blatted right over the top of that.

 

Okay, I suggest we modify the original code such that the 8K buffer in VDP ram immediately follows the PAB. Seems to be sensible. So, we need to make the following adjustment:

 

Change the beginning of the code, from this:

 

SAVEOP  EQU 6		   memory image save opcode
VDPPAB  EQU >1000	   address of PAB in VDP
VDPBUF  EQU >1800	   address of rom image in VDP
LEV3IO  EQU 8		   code for standard level 3 disk io
PNTR	EQU >8356	   address of name length in VDP pab must be written here

MYPAB   BYTE SAVEOP,0
	DATA VDPBUF
	BYTE 0,0
	DATA 8192
	BYTE 0
	BYTE 13
	TEXT 'DSK2.RS232ROM'
	EVEN

 

To this:

 

SAVEOP  EQU 6		   memory image save opcode
VDPPAB  EQU >1000	   address of PAB in VDP
LEV3IO  EQU 8		   code for standard level 3 disk io
PNTR	EQU >8356	   address of name length in VDP pab must be written here

MYPAB   BYTE SAVEOP,0
	DATA VDPBUF
	BYTE 0,0
	DATA 8192
	BYTE 0
	BYTE 13
	TEXT 'DSK2.RS232ROM'
ENDPAB  EVEN
VDPBUF  EQU VDPPAB+$-MYPAB address of rom image in VDP (follows PAB)

 

Now it's all calculated for us.

 

I'll just single step through it and see if it works...

 

Okay, it all looks good in single-step mode. The 8K VDP buffer is the first even address after the end of the PAB. Of course it's relative to >1000 since that's where the PAB goes. Anyway, the 8K buffer in VDP starts at >1018.

 

So, >1018 + >2000 = 3018. So, the buffer covers >1018 to >3017 inclusive. That's good, it doesn't blast over the disk controller variables stored at >37D8 onwards... I'll give it a go in MESS...

 

Et voila! It works! We end up with an 8192 byte PROGRAM type file on DSK2 called RS232ROM. Yes!

 

Viewing the file in the TI99DIR file viewer, we get:

 

00000000 AA 01 00 00 40 10 00 00 40 16 00 00 40 6C 00 00 ....@...@...@l..
00000010 00 00 40 F4 00 00 40 20 41 6E 05 52 53 32 33 32 ..@...@ An.RS232
00000020 40 2C 41 6E 07 52 53 32 33 32 2F 31 40 38 41 74 @,An.RS232/1@8At
00000030 07 52 53 32 33 32 2F 32 40 40 41 5E 03 50 49 4F .RS232/2@@A^.PIO
00000040 40 4A 41 5E 05 50 49 4F 2F 31 40 54 41 64 05 50 @JA^.PIO/1@TAd.P
00000050 49 4F 2F 32 40 60 41 80 07 52 53 32 33 32 2F 33 IO/2@`A..RS232/3
00000060 00 00 41 7A 07 52 53 32 33 32 2F 34 00 00 40 D2 ..Az.RS232/4..@.
00000070 00 00 08 00 03 03 45 43 45 12 43 52 45 18 4C 46 ......ECE.CRE.LF
00000080 45 1E 4E 55 45 24 44 41 45 70 42 41 45 36 50 41 E.NUE$DAEpBAE6PA
00000090 45 40 54 57 45 96 43 48 45 2A 00 00 00 28 40 B6 E@TWE.CHE*...(@.
etc etc etc...

 

Hooray!

 

Here's the completed code, as verified in MESS:

 

DEF START
REF VMBR,VMBW,DSRLNK

SAVEOP  EQU 6		   memory image save opcode
VDPPAB  EQU >1000	   address of PAB in VDP
LEV3IO  EQU 8		   code for standard level 3 disk io
PNTR	EQU >8356	   address of name length in VDP pab must be written here

MYPAB   BYTE SAVEOP,0
	DATA VDPBUF
	BYTE 0,0
	DATA 8192
	BYTE 0
	BYTE 13
	TEXT 'DSK2.RS232ROM'
ENDPAB  EVEN
VDPBUF  EQU VDPPAB+$-MYPAB address of rom image in VDP (follows PAB)

* copy pab to vdp ram
START   LI R0,VDPPAB	vdp destination
	LI R1,MYPAB	 source
	LI R2,ENDPAB-MYPAB  # bytes to transfer
	BLWP @VMBW	  send PAB to VDP

* copy DSR ROM to VDP
	LI R12,>1300	cru address of card
	SBO 0		   turn on DSR ROMS

	LI R0,VDPBUF	we'll put DSR here
	LI R1,>4000	 address of DSR ROM
	LI R2,8192	  8K of ROM
	BLWP @VMBW	  send the dsr to VDP

	SBZ 0		   switch off DSR roms

* now execute a SAVE command using DSRLNK
	LI R0,VDPPAB+9  address of name byte in VDP pab
	MOV R0,@PNTR	required for DSRLNK
	BLWP @DSRLNK
	DATA LEV3IO	 standard level 3 disk io

	RT			  return to editor assembler environment

	END

 

Classic99 can catch you out, because its 'virtual' disk controller has no VDP memory requirements... One for the lesson books!

 

So, Tim - you were 50% right... Which one do you want? The bucket or the toe nail clippings?

[+InsaneMultitasker]

Hmm... looks like the code us missing somewhere. Dunno. One for the experts I think. Anyone? Is SAVE level 3 operation? I'm a newbie at this disk io stuff.

I'd wager the problem is with the workspace (or lack thereof). Recommend you set up your environment and shut down the interrupts, ie. If the program is called from the GPLWS and DSRLNK uses that same workspace, you end up with a mess on your hands....

 

I did! As I wrote, I testes Mark's code, than added my own workspace and disabled INTs (LIMI 0). The only difference from what you suggest is that i returned with RT (after restoring R11) but that's should not be the problem, as the system seems to be stuck in DSRLNK call :'(

 

 

I would also adjust the buffer start address from 0x1800 to 0x1200. Otherwise, you are mucking around with VDP space used by some of the disk controllers. For a good overview of the space, check out this doc pages 10 and 11 in particular.

ftp://whtech.com/magazines/smartprogrammer/sp8405.pdf

 

Interesting. I will fully read and try tonight. Isn't it just for XB?

 

Ciao

Ugo

 

You are correct - the VDP documentation refers to the XB environment. However... the disk controller VDP usage is essentially the same between XB and EA, since the controller card DSR powerup defines how it is used.

 

The TI and CorComp cards differ from the Myarc cards in their overall usage. The CF7 is slightly different as well, since it uses 8 bytes additional VDP RAM to store the virtual mount points. So long as the controllers and programs play nicely, you can find the last used VDP address by reading CPU RAM 0x8370. Call FILES will increase or decrease VDP usage according to the number of files open.

[up.n.down]

Hurray! It works!

 

Here is what I finally got downloading the file through MFM a viewing it on Linux (this is why you see the TIFILES header on it):

 

00000000  07 54 49 46 49 4c 45 53  00 20 01 00 00 00 00 00  |.TIFILES. ......|
00000010  52 53 32 33 32 52 4f 4d  20 20 20 20 20 20 20 20  |RS232ROM		|
00000020  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |				|
*
00000080  aa 01 00 00 40 10 00 00  40 16 00 00 40 6c 00 00  |....@...@...@l..|
00000090  00 00 40 f4 00 00 40 20  41 6e 05 52 53 32 33 32  |..@...@ An.RS232|
000000a0  40 2c 41 6e 07 52 53 32  33 32 2f 31 40 38 41 74  |@,An.RS232/1@8At|
000000b0  07 52 53 32 33 32 2f 32  40 40 41 5e 03 50 49 4f  |.RS232/2@@A^.PIO|
000000c0  40 4a 41 5e 05 50 49 4f  2f 31 40 54 41 64 05 50  |@JA^.PIO/1@TAd.P|
000000d0  49 4f 2f 32 40 60 41 80  07 52 53 32 33 32 2f 33  |IO/2@`A..RS232/3|
000000e0  00 00 41 7a 07 52 53 32  33 32 2f 34 00 00 40 d2  |..Az.RS232/4..@.|
...

 

Thanks for all the hints to everybody, particularly to Mark "King" Willsy

 

Next steps:

 

- buy a Flash EEPROM

- hack the board (possibly with some sort bank switching to use a 32 KB EEPROM)

- program back the ROM

- disassemble ROM

- hack the ROM

- program back the ROM w/ HDX support

 

Yes, I know, I will probably end up with a useless CorComp RS232 card Does someone need one for spare parts?

 

I have way too much things to learn on the TI. I think I will stress you again in the future.

 

Ciao,

Ugo

Edited May 3, 2012 by up.n.down

[+InsaneMultitasker]

So, Tim - you were 50% right... Which one do you want? The bucket or the toe nail clippings?

Bucket, please - I can fill it at my leisure whilst I wait for code to compile Next time I'll be more careful about XB versus EA!

[Tursi]

Classic99 can catch you out, because its 'virtual' disk controller has no VDP memory requirements... One for the lesson books!

 

This one has been a real lesson for me, really. I'd like to release a DSR peripheral that works like Classic99 does and has no VDP RAM requirements, but so many people have proven that anything written on it is going to fail on systems with a standard disk controller, because people will forget to honor their needs. There has to be some kind of failure mode so that people will write compatible code (which I do view as important ).

 

Maybe I should add a warning to Classic99 when you overwrite the DSR buffers, so that you know it will fail on a real disk system...

[Willsy]

That might be useful. There are gotcha's in a number of areas though, so it depends how far you want to go. For example, for a long time, the disk IO code in TurboForth worked just fine, but would not work on real hardware or on MESS. MESS is very very good at emulating the real hardware, but useless for debugging. Debugging cartridge apps on a real 4A without some sophisticated hardware-level debugger is also a PITA.

 

It turns out that (IIRC) DSRLNK uses some scratch pad memory for it's own stuff while executing disk IO (or, possibly more correctly, the disk DSR uses scratch pad) - which is perfectly reasonable. Well, TF has code of its own installed in scratch pad too, and this was being overwritten when disk IO was performed. However, I was unable to descern that myself; it took Michael Zapf, with his 'karnal' knowledge of MESS to single step my code and see what was going on (I actually sent him my code saying "Look - there's a bug in MESS - there must be, because this works just fine in classic99!"). The disk IO was working, but would crash when returning to TF because the code had been overwritten! I just added code to restore pad to how TF likes it, and it was fine!

 

This was impossible to detect with classic99, since classic99 uses a different system to simulate disk io.

 

Like I say, it's a lesson learned. Once you know, you know, and you keep it in mind!

[+InsaneMultitasker]

Classic99 can catch you out, because its 'virtual' disk controller has no VDP memory requirements... One for the lesson books!

 

This one has been a real lesson for me, really. I'd like to release a DSR peripheral that works like Classic99 does and has no VDP RAM requirements, but so many people have proven that anything written on it is going to fail on systems with a standard disk controller, because people will forget to honor their needs. There has to be some kind of failure mode so that people will write compatible code (which I do view as important ).

 

Maybe I should add a warning to Classic99 when you overwrite the DSR buffers, so that you know it will fail on a real disk system...

When Myarc came out with its floppy controller card with 2K onboard RAM, some programs which relied upon the internal VDP memory usage set by the TI (and CorComp) floppy controller failed on this new card. The most common "failures" related to boot disk tracking. The Horizon ROS and FunnelWeb had to be modified to detect the card and modify approach accordingly. I am sure other failures have been documented over time.

 

The tricky part about implementing a "failure" is that the VDP space is usable. For example, a CALL FILES(1) or equivalent will free up VDP space normally used by the buffers wherease a CALL FILES(6) will decrease available VDP space. The VDP pointer at 0x8370 doesn't preclude someone from utilizing the memory, it simply helps the programmer determine what is technically off limits.

 

Your best bet might be to include a warning in your documentation. As we all know, users *always* read the documentation.

[Tursi]

Yes, but if my pseudo DSR detects whether the reserved VDP memory has been modified by a program while files are open (or that the pointers were modified at all), I can throw a warning as that will break on the DSRs that do use that space. That way, programs that don't care still run, and programmers who do care can check for the warning.

 

As far as scratchpad usage goes... we used every byte that was documented as safe in the E/A manual for our scratchpad E/A#5 loader project, I thought. AFAIK that worked on the real machine...? If you use areas that are not documented as safe, then you're taking a chance of different hardware configurations (which Classic99 is just a different one) breaking.

[+InsaneMultitasker]

Yes, but if my pseudo DSR detects whether the reserved VDP memory has been modified by a program while files are open (or that the pointers were modified at all), I can throw a warning as that will break on the DSRs that do use that space. That way, programs that don't care still run, and programmers who do care can check for the warning.

Makes sense. I envisioned Classic99 throwing out warning messages whenever someone ran a program that hit the reserved VDP space versus messages for programming/debugging purposes. The former could be pretty obnoxious When I get back up and running, I'll dig around for my Myarc vs. TI DSR documentation.