Re: [M100] NADSBoxes are ready (not on sale until Tuesday

[Jim Anderson]

> -Original Message-
> 
> I'm better now.  Turns out I had a really bad case of Pleurisy.  I have

Yow, that is a doozy.  Glad you're over it now.







jim

Re: [M100] Issue with sd2tpdd

[Gary Hammond]

Thanks for the testing.
Yep, line 1020 looks like a classic copy pasta from the line above. Its missing 
a right parenthesis. Mia culpa!
The version of TS-DOS I am using is 4.00

From: M100  On Behalf Of Fugu ME100
Sent: Wednesday, 16 October 2019 11:48 AM
To: m...@bitchin100.com
Subject: Re: [M100] Issue with sd2tpdd

Just tried the dice program and it loaded and saved without problems.  It did 
have a syntax error in line 1020 :)

This was using the REX vanilla TSDOS ROM version with an ATMEGA "TPDD Drive", 
however it was not using SD2TPDD.  It was using a heavily modified variant of 
DLPLUS running on a MEGA platform, it is not an Arduino board.  The file was 
only one directory level down though.  File size is 2379 as reported.

Also tried the MENU.BA program from the link Brian provided and that saved and 
loaded fine  - although it did need a reset of the machine after it was run. :)

I think REX TS-DOS appears to be working OK?

Re: [M100] Issue with sd2tpdd

[Fugu ME100]

Just tried the dice program and it loaded and saved without problems.  It did 
have a syntax error in line 1020 :)

This was using the REX vanilla TSDOS ROM version with an ATMEGA "TPDD Drive", 
however it was not using SD2TPDD.  It was using a heavily modified variant of 
DLPLUS running on a MEGA platform, it is not an Arduino board.  The file was 
only one directory level down though.  File size is 2379 as reported.

Also tried the MENU.BA program from the link Brian provided and that saved and 
loaded fine  - although it did need a reset of the machine after it was run. :)

I think REX TS-DOS appears to be working OK?

From: M100 
mailto:m100-boun...@lists.bitchin100.com>> 
on behalf of Gary Hammond mailto:ghamm...@hotmail.com>>
Reply-To: mailto:m...@bitchin100.com>>
Date: Tuesday, October 15, 2019 at 1:22 PM
To: "m...@bitchin100.com" 
mailto:m...@bitchin100.com>>
Subject: Re: [M100] Issue with sd2tpdd

Observations from the comments to date and other questions:

  *   The first 2 bytes corruption may not affect all files. (Does the file 
size matter?)
  *   Brian’s testing seems to indicate that the issue isn’t restricted to 
SD2TPDD.
  *   I tried Dans suggestion of adding the ‘break’ around line 191. It has not 
solved the trailing null problem.
  *   I have noticed references to DOS100.CO in the comments and on GitHub. 
Under what circumstances does it need to be there?
  *   How can we check that we are using the same version of TS-DOS?
  *   Is capitalisation of the filename important on the SD card?
  *   Is file size important, i.e., does the final packet of file data sent 
have to be a particular size or power of 2 or buffer rollover point to trigger 
this?
  *   Is it possible that there is also a bug in TS-DOS?

More details of my configuration:

  *   The file I am using is 2 levels down on the SD card i.e., zz -> games 
-> dice2.do
  *   The file is 2379 bytes long.
  *   The M100 has a REX fitted with TS-DOS ROM loaded.

The file I have been using follows…

1 ' Dice Program 
2 'Dice rolling program for Model 100,102,200
3 'Gary Hammond 2016
4 'ghamm...@hotmail.com
10 '*** Initialisation ***
30 DIM DR(5) ' Dice roll
40 PP=41 ' Print Position
50 DT$="*"   ' Dice dot symbol
100 '*** Main Program ***
110 GOSUB 200 'Get the number of die to roll
120 GOSUB 1000 'Randomise the random number
130 CLS
140 PRINT@292,"Roll or Quit (R/Q)?";
150 GOSUB 300 'Wait for roll/quit command
150 IF AN = 1 THEN GOSUB 400 ELSE GOTO 170 'Either roll the dice or quit
160 GOTO 140
170 CLS
180 PRINT"Goodbye!"
199 END
200 '*** Get the number of die to roll ***
210 CLS
220 PRINT@285,"How many die to roll (1-4)";
230 A$ = INKEY$
240 IF A$ = "1" OR A$ = "2" OR A$ = "3" OR A$ = "4" THEN 260
250 GOTO 230
260 DN = VAL(A$)
299 RETURN
300 '*** Wait for roll/quit command ***
310 A$ = INKEY$
320 IF A$ = "" THEN 310
330 IF A$ = "R" OR A$ = "r" OR A$ = " " THEN AN = 1:RETURN
340 IF A$ = "Q" OR A$ = "q" THEN AN = 0:RETURN
350 GOTO 310
399 RETURN
400 '*** Roll the dice 
410 CLS:PP=41 ' Print position for die
420 FOR RN = 1 TO DN
430   Y = RND(1)
440   LET Z=(RND(Y)*6+1)
450   LET DR(RN)=INT(Z)
460   GOSUB 500 'Draw the dice
470   PP = PP + 10
480 NEXT RN
499 RETURN
500 '*** Draw the dice ***
510 PRINT@PP,CHR$(235)+STRING$(5,231)+CHR$(236)
520 FOR X = 1 TO 3
530   PRINT@PP+(40*X),CHR$(233)+STRING$(5," ")+CHR$(234)
540 NEXT X
550 PRINT@PP+160,CHR$(237)+STRING$(5,232)+CHR$(238)
560 ON DR(RN) GOSUB 650,700,750,800,850,900
570 RETURN
650 '*** Draw the 1 dice face ***
660 PRINT@PP+83,DT$
670 RETURN
700 '*** Draw the 2 dice face ***
710 PRINT@PP+44,DT$
720 '
730 PRINT@PP+122,DT$
740 RETURN
750 '*** Draw the 3 dice face ***
760 PRINT@PP+44,DT$
770 PRINT@PP+83,DT$
780 PRINT@PP+122,DT$
790 RETURN
800 '*** Draw the 4 dice face ***
810 PRINT@PP+42,DT$+" "+DT$
820 '
830 PRINT@PP+122,DT$+" "+DT$
840 RETURN
850 '*** Draw the 5 dice face ***
860 PRINT@PP+42,DT$+" "+DT$
870 PRINT@PP+83,DT$
880 PRINT@PP+122,DT$+" "+DT$
890 RETURN
900 '*** Draw the 6 dice face ***
910 PRINT@PP+42,DT$+" "+DT$
920 PRINT@PP+82,DT$+" "+DT$
930 PRINT@PP+122,DT$+" "+DT$
940 RETURN
1000 REM  RANDONMISE THE RANDOM VALUE 
1010 TS = VAL(RIGHT$(TIME$,2))
1020 TM = VAL(MID$(TIME$(4,2))
1030 FOR N = 1 TO (TM * TS) + 13
1040   Y = RND(1)
1050 NEXT N
1060 RETURN

Re: [M100] Issue with sd2tpdd

[Gary Hammond]

Thanks for the explanation. I was not using the URII ROM so I didn’t need it, 
although now that I know about this, I will consider swapping over to doing 
things this way.

I have tested a 127, 128 and 129 byte file that was created on the M100 and 
saved to the SD card which in turn have been written correctly with no leading 
byte corruption or appended nulls when the SD card is read on the laptop.

I have also made a copy of my RAM image to SD using REXMGR and the size is a 
perfect 32K with no appended null. The first 2 bytes are 0x00 0x0C and a quick 
basic program to peek the bytes in RAM show that they do match the RAM image 
saved. I am assuming then that the disk image saved correctly.


From: M100  On Behalf Of Brian White
Sent: Wednesday, 16 October 2019 10:31 AM
To: m...@bitchin100.com
Subject: Re: [M100] Issue with sd2tpdd

DOS100.CO
 is a ram version of TS-DOS that Ultimate Rom II will load, run, and then 
unload all on the fly when you hit the TS-DOS menu entry in UR2.

It has to be named 
DOS100.CO
 (or 
DOS200.CO
 or 
DOSNEC.CO,
 for 200 and Nec), and be on the root of the disk.

The "disk" may be any kind of tpdd, from a real tpdd with a floppy, to 
laddiealpha to sd2tpdd.

You don't need any other dos installed either in ram or rom. You don't need 
floppy.co
 for instance, or even teeny. UR2 has just enough code to read 
dos100.co
 from a disk, then ts-dos in ram does the rest.

It's ingenious because, not only does it mean you can have ts-dos without 
taking up room either on the rom nor in ram (except while actually running) it 
also means 30 years after UR2 was written in stone and shipped, you can have an 
updated versions of TS-DOS without crafting a new UR2 rom.

And it hardly gets in the way having to have a disk around for it to work, 
because, it's a dos we're talking about. If you even want to use it at all, 
then almost by definition you have a drive and a disk.

I have not tried anything crazy like taking a copy of 
teeny.co
 and naming it 
dos100.co
 to see if UR2 can use teeny on-the-fly in place of ts-dos.

--
bkw

Re: [M100] NADSBoxes are ready (not on sale until Tuesday

[Ken Pettit]

Hey Guys,

I'm better now.  Turns out I had a really bad case of Pleurisy.  I have 
the NADSBoxes all packaged and almost ready to go.  Just need to print 
shipping labels and fill out 3-4 international customs forms, then I can 
get all of them shipped.  Probably by Thursday ... sorry it is taking a 
while ... got sick exactly at the wrong time (not that here is ever a 
right time).


Ken

On 10/15/19 12:28 PM, james.z...@gmail.com wrote:

Hey Ken

How are you doing? Thought I’d check up on the status of the NADSBoxes. Don’t 
know whether I missed a status update.

Cheers
James


Sent from my iPad


On 22 Sep 2019, at 4:44 pm, Ken Pettit  wrote:


On 9/22/19 7:51 AM, Ibi Sum wrote:
I’m definitely interested in buying one!  I’ll use it with my Olivetti ... how 
to pay!?

This is the current plan:

1.  On this Tuesday at 11:00am PDT, I will send an email to the Club100 list 
with a link at Club100 to a NADSBox order form.
2.  The order form will be fairly simple ... supply Name, address and email.  
The form will send an order request to my Club100 email account.
3.  The first 9 orders recieved in my email inbox get the NADSBoxes.
4.  After I recieve 9 orders, I will disable the order form.
5.  I will send a Paypal invoice to the 9 people who place the orders first.
6.  Pay the paypal invoice via PayPal's secure credit card processing system.
7.  I will ship the NADSBoxes after the invoices are paid.


To give people in Europe, Asia, Australia, New Zealand, etc, a chance, I will 
re-enable the order form on Tuesday at 11:00pm PDT to sell the remaining 6 
NADSBoxes and send another email on the Club100 list.  Then repeat steps 2-7 
(sending invoices most likely the next morning).

Ken

Re: [M100] Issue with sd2tpdd

[Brian White]

DOS100.CO is a ram version of TS-DOS that Ultimate Rom II will load, run,
and then unload all on the fly when you hit the TS-DOS menu entry in UR2.

It has to be named DOS100.CO (or DOS200.CO or DOSNEC.CO, for 200 and Nec),
and be on the root of the disk.

The "disk" may be any kind of tpdd, from a real tpdd with a floppy, to
laddiealpha to sd2tpdd.

You don't need any other dos installed either in ram or rom. You don't need
floppy.co for instance, or even teeny. UR2 has just enough code to read
dos100.co from a disk, then ts-dos in ram does the rest.

It's ingenious because, not only does it mean you can have ts-dos without
taking up room either on the rom nor in ram (except while actually running)
it also means 30 years after UR2 was written in stone and shipped, you can
have an updated versions of TS-DOS without crafting a new UR2 rom.

And it hardly gets in the way having to have a disk around for it to work,
because, it's a dos we're talking about. If you even want to use it at all,
then almost by definition you have a drive and a disk.

I have not tried anything crazy like taking a copy of teeny.co and naming
it dos100.co to see if UR2 can use teeny on-the-fly in place of ts-dos.

-- 
bkw


On Tue, Oct 15, 2019, 4:22 PM Gary Hammond  wrote:

> Observations from the comments to date and other questions:
>
>- The first 2 bytes corruption may not affect all files. (Does the
>file size matter?)
>- Brian’s testing seems to indicate that the issue isn’t restricted to
>SD2TPDD.
>- I tried Dans suggestion of adding the ‘break’ around line 191. It
>has not solved the trailing null problem.
>- I have noticed references to DOS100.CO in the comments and on
>GitHub. Under what circumstances does it need to be there?
>- How can we check that we are using the same version of TS-DOS?
>- Is capitalisation of the filename important on the SD card?
>- Is file size important, i.e., does the final packet of file data
>sent have to be a particular size or power of 2 or buffer rollover point to
>trigger this?
>- Is it possible that there is also a bug in TS-DOS?
>
>
>
> More details of my configuration:
>
>- The file I am using is 2 levels down on the SD card i.e., zz ->
>games -> dice2.do
>- The file is 2379 bytes long.
>- The M100 has a REX fitted with TS-DOS ROM loaded.
>
>
>
> The file I have been using follows…
>
>
>
> 1 ' Dice Program 
>
> 2 'Dice rolling program for Model 100,102,200
>
> 3 'Gary Hammond 2016
>
> 4 'ghamm...@hotmail.com
>
> 10 '*** Initialisation ***
>
> 30 DIM DR(5) ' Dice roll
>
> 40 PP=41 ' Print Position
>
> 50 DT$="*"   ' Dice dot symbol
>
> 100 '*** Main Program ***
>
> 110 GOSUB 200 'Get the number of die to roll
>
> 120 GOSUB 1000 'Randomise the random number
>
> 130 CLS
>
> 140 PRINT@292,"Roll or Quit (R/Q)?";
>
> 150 GOSUB 300 'Wait for roll/quit command
>
> 150 IF AN = 1 THEN GOSUB 400 ELSE GOTO 170 'Either roll the dice or quit
>
> 160 GOTO 140
>
> 170 CLS
>
> 180 PRINT"Goodbye!"
>
> 199 END
>
> 200 '*** Get the number of die to roll ***
>
> 210 CLS
>
> 220 PRINT@285,"How many die to roll (1-4)";
>
> 230 A$ = INKEY$
>
> 240 IF A$ = "1" OR A$ = "2" OR A$ = "3" OR A$ = "4" THEN 260
>
> 250 GOTO 230
>
> 260 DN = VAL(A$)
>
> 299 RETURN
>
> 300 '*** Wait for roll/quit command ***
>
> 310 A$ = INKEY$
>
> 320 IF A$ = "" THEN 310
>
> 330 IF A$ = "R" OR A$ = "r" OR A$ = " " THEN AN = 1:RETURN
>
> 340 IF A$ = "Q" OR A$ = "q" THEN AN = 0:RETURN
>
> 350 GOTO 310
>
> 399 RETURN
>
> 400 '*** Roll the dice 
>
> 410 CLS:PP=41 ' Print position for die
>
> 420 FOR RN = 1 TO DN
>
> 430   Y = RND(1)
>
> 440   LET Z=(RND(Y)*6+1)
>
> 450   LET DR(RN)=INT(Z)
>
> 460   GOSUB 500 'Draw the dice
>
> 470   PP = PP + 10
>
> 480 NEXT RN
>
> 499 RETURN
>
> 500 '*** Draw the dice ***
>
> 510 PRINT@PP,CHR$(235)+STRING$(5,231)+CHR$(236)
>
> 520 FOR X = 1 TO 3
>
> 530   PRINT@PP+(40*X),CHR$(233)+STRING$(5," ")+CHR$(234)
>
> 540 NEXT X
>
> 550 PRINT@PP+160,CHR$(237)+STRING$(5,232)+CHR$(238)
>
> 560 ON DR(RN) GOSUB 650,700,750,800,850,900
>
> 570 RETURN
>
> 650 '*** Draw the 1 dice face ***
>
> 660 PRINT@PP+83,DT$
>
> 670 RETURN
>
> 700 '*** Draw the 2 dice face ***
>
> 710 PRINT@PP+44,DT$
>
> 720 '
>
> 730 PRINT@PP+122,DT$
>
> 740 RETURN
>
> 750 '*** Draw the 3 dice face ***
>
> 760 PRINT@PP+44,DT$
>
> 770 PRINT@PP+83,DT$
>
> 780 PRINT@PP+122,DT$
>
> 790 RETURN
>
> 800 '*** Draw the 4 dice face ***
>
> 810 PRINT@PP+42,DT$+" "+DT$
>
> 820 '
>
> 830 PRINT@PP+122,DT$+" "+DT$
>
> 840 RETURN
>
> 850 '*** Draw the 5 dice face ***
>
> 860 PRINT@PP+42,DT$+" "+DT$
>
> 870 PRINT@PP+83,DT$
>
> 880 PRINT@PP+122,DT$+" "+DT$
>
> 890 RETURN
>
> 900 '*** Draw the 6 dice face ***
>
> 910 PRINT@PP+42,DT$+" "+DT$
>
> 920 PRINT@PP+82,DT$+" "+DT$
>
> 930 PRINT@PP+122,DT$+" "+DT$
>
> 940 RETURN
>
> 1000 REM  RANDONMISE THE RANDOM VALUE 
>
> 1010 TS = VAL(RIGHT$(TIME$,2))
>
> 1020 TM = VAL(MID$(TIME$(4,2))
>
> 1030 FOR N = 1 TO (TM * 

Re: [M100] Issue with sd2tpdd

[Gary Hammond]

Observations from the comments to date and other questions:

  *   The first 2 bytes corruption may not affect all files. (Does the file 
size matter?)
  *   Brian’s testing seems to indicate that the issue isn’t restricted to 
SD2TPDD.
  *   I tried Dans suggestion of adding the ‘break’ around line 191. It has not 
solved the trailing null problem.
  *   I have noticed references to DOS100.CO in the comments and on GitHub. 
Under what circumstances does it need to be there?
  *   How can we check that we are using the same version of TS-DOS?
  *   Is capitalisation of the filename important on the SD card?
  *   Is file size important, i.e., does the final packet of file data sent 
have to be a particular size or power of 2 or buffer rollover point to trigger 
this?
  *   Is it possible that there is also a bug in TS-DOS?

More details of my configuration:

  *   The file I am using is 2 levels down on the SD card i.e., zz -> games 
-> dice2.do
  *   The file is 2379 bytes long.
  *   The M100 has a REX fitted with TS-DOS ROM loaded.

The file I have been using follows…

1 ' Dice Program 
2 'Dice rolling program for Model 100,102,200
3 'Gary Hammond 2016
4 'ghamm...@hotmail.com
10 '*** Initialisation ***
30 DIM DR(5) ' Dice roll
40 PP=41 ' Print Position
50 DT$="*"   ' Dice dot symbol
100 '*** Main Program ***
110 GOSUB 200 'Get the number of die to roll
120 GOSUB 1000 'Randomise the random number
130 CLS
140 PRINT@292,"Roll or Quit (R/Q)?";
150 GOSUB 300 'Wait for roll/quit command
150 IF AN = 1 THEN GOSUB 400 ELSE GOTO 170 'Either roll the dice or quit
160 GOTO 140
170 CLS
180 PRINT"Goodbye!"
199 END
200 '*** Get the number of die to roll ***
210 CLS
220 PRINT@285,"How many die to roll (1-4)";
230 A$ = INKEY$
240 IF A$ = "1" OR A$ = "2" OR A$ = "3" OR A$ = "4" THEN 260
250 GOTO 230
260 DN = VAL(A$)
299 RETURN
300 '*** Wait for roll/quit command ***
310 A$ = INKEY$
320 IF A$ = "" THEN 310
330 IF A$ = "R" OR A$ = "r" OR A$ = " " THEN AN = 1:RETURN
340 IF A$ = "Q" OR A$ = "q" THEN AN = 0:RETURN
350 GOTO 310
399 RETURN
400 '*** Roll the dice 
410 CLS:PP=41 ' Print position for die
420 FOR RN = 1 TO DN
430   Y = RND(1)
440   LET Z=(RND(Y)*6+1)
450   LET DR(RN)=INT(Z)
460   GOSUB 500 'Draw the dice
470   PP = PP + 10
480 NEXT RN
499 RETURN
500 '*** Draw the dice ***
510 PRINT@PP,CHR$(235)+STRING$(5,231)+CHR$(236)
520 FOR X = 1 TO 3
530   PRINT@PP+(40*X),CHR$(233)+STRING$(5," ")+CHR$(234)
540 NEXT X
550 PRINT@PP+160,CHR$(237)+STRING$(5,232)+CHR$(238)
560 ON DR(RN) GOSUB 650,700,750,800,850,900
570 RETURN
650 '*** Draw the 1 dice face ***
660 PRINT@PP+83,DT$
670 RETURN
700 '*** Draw the 2 dice face ***
710 PRINT@PP+44,DT$
720 '
730 PRINT@PP+122,DT$
740 RETURN
750 '*** Draw the 3 dice face ***
760 PRINT@PP+44,DT$
770 PRINT@PP+83,DT$
780 PRINT@PP+122,DT$
790 RETURN
800 '*** Draw the 4 dice face ***
810 PRINT@PP+42,DT$+" "+DT$
820 '
830 PRINT@PP+122,DT$+" "+DT$
840 RETURN
850 '*** Draw the 5 dice face ***
860 PRINT@PP+42,DT$+" "+DT$
870 PRINT@PP+83,DT$
880 PRINT@PP+122,DT$+" "+DT$
890 RETURN
900 '*** Draw the 6 dice face ***
910 PRINT@PP+42,DT$+" "+DT$
920 PRINT@PP+82,DT$+" "+DT$
930 PRINT@PP+122,DT$+" "+DT$
940 RETURN
1000 REM  RANDONMISE THE RANDOM VALUE 
1010 TS = VAL(RIGHT$(TIME$,2))
1020 TM = VAL(MID$(TIME$(4,2))
1030 FOR N = 1 TO (TM * TS) + 13
1040   Y = RND(1)
1050 NEXT N
1060 RETURN

Re: [M100] Issue with sd2tpdd

[John R. Hogerhuis]

I have minor suggestions: name the states in your state machine. Constants
/ preprocessor labels are "free."

When you finish processing a command reset the front and rear for the
receive buffer to zero. Using a wrapround queue is probably making the code
more complicated / less efficient.

Log to your debug port if you overflow your buffer.

Check the checksum on incoming requests and log if they are corrupt.

Head and tail names seems reverse of what is typical. It is a little
disorienting.

Also a comment that you're relying on the receive buffer being exactly 256
bytes and the indices being bytes deserves a comment.

-- John.



On Tue, Oct 15, 2019, 12:22 PM Gary Hammond  wrote:

> I woke up this morning to an inbox full of useful suggestions and ideas,
> and the amount of excellent quality feedback has been amazing.
>
> I now have a bunch of work to do to try some of the ideas and do some
> further investigation.
>
> This list is awesome!
>
>
>
> A few of quotes from my career as a software developer…
>
> “Who wrote this crap!…(looks at SVN blame)…oh. It was me ☹”
>
> “If you get N software developers to come up with a solution, you will get
> N+1 solutions to the problem”
>
> “Sometimes there are many solutions to the same problem, and the
> differences in choosing which one is the ‘right’ one comes down to personal
> preferences.”
>

Re: [M100] NADSBoxes are ready (not on sale until Tuesday

[james . zeun]

Hey Ken

How are you doing? Thought I’d check up on the status of the NADSBoxes. Don’t 
know whether I missed a status update.

Cheers
James


Sent from my iPad

> On 22 Sep 2019, at 4:44 pm, Ken Pettit  wrote:
> 
>> On 9/22/19 7:51 AM, Ibi Sum wrote:
>> I’m definitely interested in buying one!  I’ll use it with my Olivetti ... 
>> how to pay!?
> 
> This is the current plan:
> 
> 1.  On this Tuesday at 11:00am PDT, I will send an email to the Club100 list 
> with a link at Club100 to a NADSBox order form.
> 2.  The order form will be fairly simple ... supply Name, address and email.  
> The form will send an order request to my Club100 email account.
> 3.  The first 9 orders recieved in my email inbox get the NADSBoxes.
> 4.  After I recieve 9 orders, I will disable the order form.
> 5.  I will send a Paypal invoice to the 9 people who place the orders first.
> 6.  Pay the paypal invoice via PayPal's secure credit card processing system.
> 7.  I will ship the NADSBoxes after the invoices are paid.
> 
> 
> To give people in Europe, Asia, Australia, New Zealand, etc, a chance, I will 
> re-enable the order form on Tuesday at 11:00pm PDT to sell the remaining 6 
> NADSBoxes and send another email on the Club100 list.  Then repeat steps 2-7 
> (sending invoices most likely the next morning).
> 
> Ken

Re: [M100] Issue with sd2tpdd

[Gary Hammond]

I woke up this morning to an inbox full of useful suggestions and ideas, and 
the amount of excellent quality feedback has been amazing.
I now have a bunch of work to do to try some of the ideas and do some further 
investigation.
This list is awesome!

A few of quotes from my career as a software developer…
“Who wrote this crap!…(looks at SVN blame)…oh. It was me ☹”
“If you get N software developers to come up with a solution, you will get N+1 
solutions to the problem”
“Sometimes there are many solutions to the same problem, and the differences in 
choosing which one is the ‘right’ one comes down to personal preferences.”

Re: [M100] Issue with sd2tpdd

[Dan Higdon]

Sure, there are a lot of things I'd do differently if it were my program.
:)

On Tue, Oct 15, 2019 at 10:37 AM Fugu ME100  wrote:

> I would probably just use memset rather than the for loop. :)
>
> From: M100  on behalf of Dan Higdon <
> therealh...@gmail.com>
> Reply-To: 
> Date: Tuesday, October 15, 2019 at 8:10 AM
> To: 
> Subject: Re: [M100] Issue with sd2tpdd
>
> I'd also consider re-writing clear buffer to take a (char *c) parameter,
> like this:
>
> void clearBuffer(*char** buffer, int bufferSize){ //Fills the buffer with
> 0x00
>   for(int i=0; i *buffer[i] = '\0';*
>   }
> }
>
>

Re: [M100] Issue with sd2tpdd

[Brian K. White]

On 10/15/19 11:37 AM, Fugu ME100 wrote:

I would probably just use memset rather than the for loop. :)


I apparently dispensed with the entire operation.
The function does not exist in my version.
https://github.com/bkw777/SD2TPDD/tree/bkw_al32u4

I don't think I'm getting any trailing nulls either. (I'll have to test 
more times with more different files to be certain, since Gary said 
different files behaved differently.


And I don't get any compiler errors even with verbose messages turned on:
---
/home/bkw/arduino-1.8.10/arduino-builder -dump-prefs -logger=machine 
-hardware /home/bkw/arduino-1.8.10/hardware -hardware 
/home/bkw/.arduino15/packages -tools 
/home/bkw/arduino-1.8.10/tools-builder -tools 
/home/bkw/arduino-1.8.10/hardware/tools/avr -tools 
/home/bkw/.arduino15/packages -built-in-libraries 
/home/bkw/arduino-1.8.10/libraries -libraries 
/home/bkw/Arduino/libraries -fqbn=adafruit:avr:feather32u4 
-ide-version=10810 -build-path /tmp/arduino_build_375308 -warnings=none 
-prefs=build.warn_data_percentage=75 
-prefs=runtime.tools.avrdude.path=/home/bkw/.arduino15/packages/arduino/tools/avrdude/6.3.0-arduino17 
-prefs=runtime.tools.avrdude-6.3.0-arduino17.path=/home/bkw/.arduino15/packages/arduino/tools/avrdude/6.3.0-arduino17 
-prefs=runtime.tools.arduinoOTA.path=/home/bkw/.arduino15/packages/arduino/tools/arduinoOTA/1.3.0 
-prefs=runtime.tools.arduinoOTA-1.3.0.path=/home/bkw/.arduino15/packages/arduino/tools/arduinoOTA/1.3.0 
-prefs=runtime.tools.avr-gcc.path=/home/bkw/.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino5 
-prefs=runtime.tools.avr-gcc-7.3.0-atmel3.6.1-arduino5.path=/home/bkw/.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino5 
-verbose /home/bkw/src/SD2TPDD/SD2TPDD.ino
/home/bkw/arduino-1.8.10/arduino-builder -compile -logger=machine 
-hardware /home/bkw/arduino-1.8.10/hardware -hardware 
/home/bkw/.arduino15/packages -tools 
/home/bkw/arduino-1.8.10/tools-builder -tools 
/home/bkw/arduino-1.8.10/hardware/tools/avr -tools 
/home/bkw/.arduino15/packages -built-in-libraries 
/home/bkw/arduino-1.8.10/libraries -libraries 
/home/bkw/Arduino/libraries -fqbn=adafruit:avr:feather32u4 
-ide-version=10810 -build-path /tmp/arduino_build_375308 -warnings=none 
-prefs=build.warn_data_percentage=75 
-prefs=runtime.tools.avrdude.path=/home/bkw/.arduino15/packages/arduino/tools/avrdude/6.3.0-arduino17 
-prefs=runtime.tools.avrdude-6.3.0-arduino17.path=/home/bkw/.arduino15/packages/arduino/tools/avrdude/6.3.0-arduino17 
-prefs=runtime.tools.arduinoOTA.path=/home/bkw/.arduino15/packages/arduino/tools/arduinoOTA/1.3.0 
-prefs=runtime.tools.arduinoOTA-1.3.0.path=/home/bkw/.arduino15/packages/arduino/tools/arduinoOTA/1.3.0 
-prefs=runtime.tools.avr-gcc.path=/home/bkw/.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino5 
-prefs=runtime.tools.avr-gcc-7.3.0-atmel3.6.1-arduino5.path=/home/bkw/.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino5 
-verbose /home/bkw/src/SD2TPDD/SD2TPDD.ino
Using board 'feather32u4' from platform in folder: 
/home/bkw/.arduino15/packages/adafruit/hardware/avr/1.4.13
Using core 'arduino' from platform in folder: 
/home/bkw/arduino-1.8.10/hardware/arduino/avr

Detecting libraries used...
/home/bkw/.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino5/bin/avr-g++ 
-c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions 
-ffunction-sections -fdata-sections -fno-threadsafe-statics 
-Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega32u4 
-DF_CPU=800L -DARDUINO=10810 -DARDUINO_AVR_FEATHER32U4 
-DARDUINO_ARCH_AVR -DUSB_VID=0x239A -DUSB_PID=0x800C 
"-DUSB_MANUFACTURER=\"Adafruit\"" "-DUSB_PRODUCT=\"Feather 32u4\"" 
-I/home/bkw/arduino-1.8.10/hardware/arduino/avr/cores/arduino 
-I/home/bkw/.arduino15/packages/adafruit/hardware/avr/1.4.13/variants/feather32u4 
/tmp/arduino_build_375308/sketch/SD2TPDD.ino.cpp -o /dev/null

Alternatives for SdFat.h: [SdFat@1.1.0]
ResolveLibrary(SdFat.h)
  -> candidates: [SdFat@1.1.0]
/home/bkw/.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino5/bin/avr-g++ 
-c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions 
-ffunction-sections -fdata-sections -fno-threadsafe-statics 
-Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega32u4 
-DF_CPU=800L -DARDUINO=10810 -DARDUINO_AVR_FEATHER32U4 
-DARDUINO_ARCH_AVR -DUSB_VID=0x239A -DUSB_PID=0x800C 
"-DUSB_MANUFACTURER=\"Adafruit\"" "-DUSB_PRODUCT=\"Feather 32u4\"" 
-I/home/bkw/arduino-1.8.10/hardware/arduino/avr/cores/arduino 
-I/home/bkw/.arduino15/packages/adafruit/hardware/avr/1.4.13/variants/feather32u4 
-I/home/bkw/Arduino/libraries/SdFat/src 
/tmp/arduino_build_375308/sketch/SD2TPDD.ino.cpp -o /dev/null

Alternatives for SPI.h: [SPI@1.0]
ResolveLibrary(SPI.h)
  -> candidates: [SPI@1.0]
/home/bkw/.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino5/bin/avr-g++ 
-c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions 
-ffunction-sections -fdata-sections -fno-threadsafe-statics 

Re: [M100] Issue with sd2tpdd

[Stephen Adolph]

what does MENU.BA provide for you in this case?
I have made a variant of MENU.BA that is a general add-on for M100.  Not
related to PG-Designs RAM modules.

On Tue, Oct 15, 2019 at 11:13 AM Fugu ME100  wrote:

> This is normal behavior it is the 00H - Directory Reference message,
> requesting the first directory block and subsequent blocks. The byte after
> the attribute specifies the type.  I agree it does look weird when you see
> it happening.
>
> Do you happen to have a link to the MENU.BA file I would like to try the
> exercise see if the results are the same, thnx.  However first I need to
> fix my M100 it now has a clock problem when I powered it up this morning,
> it was working yesterday :)
>
>
>
> On 15/10/19, 3:28 AM, "M100 on behalf of Brian K. White"
>  wrote:
> 
> >There does seem to be something weird with SD2TPDD though (at least my
> >hacked-up version).
> >If I enable debugging to the serial console, reading a file from SD to
> >M100 generates traffic that looks questionable.
> >There's a packet that repeats a bunch of times that looks like it has
> >the filename minus the first letter. No idea what that's about. Almost
> >looks like it's doing that operation wrong, and TS-DOS is retrying a
> >bunch of times before giving up.
> >The reverse operation, writing the same file from M100 to SD, generated
> >far fewer packets, and didn't have any packets that looked like missing
> >the first letter of the filename.
> 
>
>
>

Re: [M100] Issue with sd2tpdd

[Brian K. White]

http://www.tmne.com/downloads.html
http://www.tmne.com/downloads/pc/menu_ba.zip

or http://www.club100.org/library/libups.html
And scroll down to Richard Hanson

It will be of little use unless you have a PG Designs ram expansion, but 
it should run and install itself.
It's a very exotic .ba file that must be transferred by TPDD, or at 
least, can not be transferred by saving as ascii and capturing in telcom.


When it's installed, it's invisible. You have to type "0menu" blindly at 
the main menu to activate it, and then all you should see is the F-key 
labels get Bnk1 Bnk2 ... Bnk8

You'll want to cold reset to clear it out.

--
bkw


On 10/15/19 11:13 AM, Fugu ME100 wrote:

This is normal behavior it is the 00H - Directory Reference message,
requesting the first directory block and subsequent blocks. The byte after
the attribute specifies the type.  I agree it does look weird when you see
it happening.

Do you happen to have a link to the MENU.BA file I would like to try the
exercise see if the results are the same, thnx.  However first I need to
fix my M100 it now has a clock problem when I powered it up this morning,
it was working yesterday :)



On 15/10/19, 3:28 AM, "M100 on behalf of Brian K. White"
 wrote:


There does seem to be something weird with SD2TPDD though (at least my
hacked-up version).
If I enable debugging to the serial console, reading a file from SD to
M100 generates traffic that looks questionable.
There's a packet that repeats a bunch of times that looks like it has
the filename minus the first letter. No idea what that's about. Almost
looks like it's doing that operation wrong, and TS-DOS is retrying a
bunch of times before giving up.
The reverse operation, writing the same file from M100 to SD, generated
far fewer packets, and didn't have any packets that looked like missing
the first letter of the filename.

Re: [M100] Issue with sd2tpdd

[Fugu ME100]

I would probably just use memset rather than the for loop. :)

From: M100 
mailto:m100-boun...@lists.bitchin100.com>> 
on behalf of Dan Higdon mailto:therealh...@gmail.com>>
Reply-To: mailto:m...@bitchin100.com>>
Date: Tuesday, October 15, 2019 at 8:10 AM
To: mailto:m...@bitchin100.com>>
Subject: Re: [M100] Issue with sd2tpdd

I'd also consider re-writing clear buffer to take a (char *c) parameter, like 
this:

void clearBuffer(char* buffer, int bufferSize){ //Fills the buffer with 0x00
  for(int i=0; i

Re: [M100] Issue with sd2tpdd

[Fugu ME100]

This is normal behavior it is the 00H - Directory Reference message,
requesting the first directory block and subsequent blocks. The byte after
the attribute specifies the type.  I agree it does look weird when you see
it happening.  

Do you happen to have a link to the MENU.BA file I would like to try the
exercise see if the results are the same, thnx.  However first I need to
fix my M100 it now has a clock problem when I powered it up this morning,
it was working yesterday :)



On 15/10/19, 3:28 AM, "M100 on behalf of Brian K. White"
 wrote:

>There does seem to be something weird with SD2TPDD though (at least my
>hacked-up version).
>If I enable debugging to the serial console, reading a file from SD to
>M100 generates traffic that looks questionable.
>There's a packet that repeats a bunch of times that looks like it has
>the filename minus the first letter. No idea what that's about. Almost
>looks like it's doing that operation wrong, and TS-DOS is retrying a
>bunch of times before giving up.
>The reverse operation, writing the same file from M100 to SD, generated
>far fewer packets, and didn't have any packets that looked like missing
>the first letter of the filename.

Re: [M100] Issue with sd2tpdd

[Dan Higdon]

I'd also consider re-writing clear buffer to take a (char *c) parameter,
like this:

void clearBuffer(*char** buffer, int bufferSize){ //Fills the buffer with
0x00
  for(int i=0; i wrote:

> A couple of notes:
> After line 191 (term = i;), insert a break statement. This may actually
> fix the extra null problem.
>
> Change the declaration of the parameter in 147 to (char const * c). Do the
> same on line 98. This will silence a lot of the warnings.
>
> On Tue, Oct 15, 2019 at 5:45 AM Brian K. White  wrote:
>
>> I'll do some more methodical testing to try to duplicate.
>> --
>> bkw
>>
>> On 10/15/19 4:55 AM, Gary Hammond wrote:
>> >
>> > With the code for sd2tpdd from GitHub, the compiler was issuing the
>> > warnings below. I have gone through and corrected them and the
>> > compiler is now happy and the randomness in the first 2 characters is
>> > less random. They are still garbage characters but now they are nearly
>> > consistently the same garbage for a given file.
>> >
>> > For example, for 3 runs of the load/save of the same file, I got the
>> > following first 2 bytes (hex)
>> >
>> > 5C 89
>> >
>> > 97 8A
>> >
>> > 5C 89
>> >
>> > On a different file I got 1B 8A
>> >
>> > The compiler warnings were:
>> >
>> > 184:33: warning: invalid conversion from 'char*' to 'byte* {aka
>> > unsigned char*}' [-fpermissive]
>> >
>> > 92:6: note:   initializing argument 1 of 'void clearBuffer(byte*, int)'
>> >
>> > 253:30: warning: ISO C++ forbids converting a string constant to
>> > 'char*' [-Wwrite-strings]
>> >
>> > 379:28: warning: ISO C++ forbids converting a string constant to
>> > 'char*' [-Wwrite-strings]
>> >
>> > 473:24: warning: ISO C++ forbids converting a string constant to
>> > 'char*' [-Wwrite-strings]
>> >
>> > 498:24: warning: ISO C++ forbids converting a string constant to
>> > 'char*' [-Wwrite-strings]
>> >
>> > 522:34: warning: ISO C++ forbids converting a string constant to
>> > 'char*' [-Wwrite-strings]
>> >
>> > The NULL character is still being appended to the end of the file…no
>> > luck so far chasing that one down.
>> >
>> > To help with those who can confirm that they have their board working
>> > fine, I am using Arduino 1.8.10 for build and upload.
>> >
>> > The GitHub page for the source I am using is
>> > https://github.com/TangentDelta/SD2TPDD in case I am using the wrong
>> one.
>> >
>> > I have now tried my 2 slightly suspect AliExpress Arduino Mega clones
>> > and various combinations of el cheapo SD card readers and shop bought
>> > ones. The genuine Arduino Mega I ordered from arduino.cc arrived today
>> > so have swapped out the clones for the genuine article and still no
>> luck.
>> >
>>
>>

Re: [M100] Issue with sd2tpdd

[Dan Higdon]

A couple of notes:
After line 191 (term = i;), insert a break statement. This may actually fix
the extra null problem.

Change the declaration of the parameter in 147 to (char const * c). Do the
same on line 98. This will silence a lot of the warnings.

On Tue, Oct 15, 2019 at 5:45 AM Brian K. White  wrote:

> I'll do some more methodical testing to try to duplicate.
> --
> bkw
>
> On 10/15/19 4:55 AM, Gary Hammond wrote:
> >
> > With the code for sd2tpdd from GitHub, the compiler was issuing the
> > warnings below. I have gone through and corrected them and the
> > compiler is now happy and the randomness in the first 2 characters is
> > less random. They are still garbage characters but now they are nearly
> > consistently the same garbage for a given file.
> >
> > For example, for 3 runs of the load/save of the same file, I got the
> > following first 2 bytes (hex)
> >
> > 5C 89
> >
> > 97 8A
> >
> > 5C 89
> >
> > On a different file I got 1B 8A
> >
> > The compiler warnings were:
> >
> > 184:33: warning: invalid conversion from 'char*' to 'byte* {aka
> > unsigned char*}' [-fpermissive]
> >
> > 92:6: note:   initializing argument 1 of 'void clearBuffer(byte*, int)'
> >
> > 253:30: warning: ISO C++ forbids converting a string constant to
> > 'char*' [-Wwrite-strings]
> >
> > 379:28: warning: ISO C++ forbids converting a string constant to
> > 'char*' [-Wwrite-strings]
> >
> > 473:24: warning: ISO C++ forbids converting a string constant to
> > 'char*' [-Wwrite-strings]
> >
> > 498:24: warning: ISO C++ forbids converting a string constant to
> > 'char*' [-Wwrite-strings]
> >
> > 522:34: warning: ISO C++ forbids converting a string constant to
> > 'char*' [-Wwrite-strings]
> >
> > The NULL character is still being appended to the end of the file…no
> > luck so far chasing that one down.
> >
> > To help with those who can confirm that they have their board working
> > fine, I am using Arduino 1.8.10 for build and upload.
> >
> > The GitHub page for the source I am using is
> > https://github.com/TangentDelta/SD2TPDD in case I am using the wrong
> one.
> >
> > I have now tried my 2 slightly suspect AliExpress Arduino Mega clones
> > and various combinations of el cheapo SD card readers and shop bought
> > ones. The genuine Arduino Mega I ordered from arduino.cc arrived today
> > so have swapped out the clones for the genuine article and still no luck.
> >
>
>

Re: [M100] Issue with sd2tpdd

[Brian K. White]

I'll do some more methodical testing to try to duplicate.
--
bkw

On 10/15/19 4:55 AM, Gary Hammond wrote:


With the code for sd2tpdd from GitHub, the compiler was issuing the 
warnings below. I have gone through and corrected them and the 
compiler is now happy and the randomness in the first 2 characters is 
less random. They are still garbage characters but now they are nearly 
consistently the same garbage for a given file.


For example, for 3 runs of the load/save of the same file, I got the 
following first 2 bytes (hex)


5C 89

97 8A

5C 89

On a different file I got 1B 8A

The compiler warnings were:

184:33: warning: invalid conversion from 'char*' to 'byte* {aka 
unsigned char*}' [-fpermissive]


92:6: note:   initializing argument 1 of 'void clearBuffer(byte*, int)'

253:30: warning: ISO C++ forbids converting a string constant to 
'char*' [-Wwrite-strings]


379:28: warning: ISO C++ forbids converting a string constant to 
'char*' [-Wwrite-strings]


473:24: warning: ISO C++ forbids converting a string constant to 
'char*' [-Wwrite-strings]


498:24: warning: ISO C++ forbids converting a string constant to 
'char*' [-Wwrite-strings]


522:34: warning: ISO C++ forbids converting a string constant to 
'char*' [-Wwrite-strings]


The NULL character is still being appended to the end of the file…no 
luck so far chasing that one down.


To help with those who can confirm that they have their board working 
fine, I am using Arduino 1.8.10 for build and upload.


The GitHub page for the source I am using is 
https://github.com/TangentDelta/SD2TPDD in case I am using the wrong one.


I have now tried my 2 slightly suspect AliExpress Arduino Mega clones 
and various combinations of el cheapo SD card readers and shop bought 
ones. The genuine Arduino Mega I ordered from arduino.cc arrived today 
so have swapped out the clones for the genuine article and still no luck.

Re: [M100] Issue with sd2tpdd

[Brian K. White]

I can't duplicate the problem consistently, at least not with my own 
modified version.


https://github.com/bkw777/SD2TPDD/tree/bkw_al32u4

("bkw_al32u4" branch)

I DO see a file change, always in the same way, but only a certain BA 
file, AND, I see that file change the same way with bot dlplus and 
laddiealpha


If I create a text file ABCD.DO only containing "1234" I can copy it to 
the SD card, and then look at the SD card on linux, the file is good.


So that tests going from M100 to SD.

If I copy the file from the SD card to the M100 vi arduino, and then 
copy the file from the M100 to linux via dlplus, the file is good.


So that tests going from SD to M100 (assuming we trust dlplus, which I 
do, plus see later).


Same goes for ABCD.BA containing "10'1234"

But if I take MENU.BA v 2.01 (PG Designs ram expansion util)


First few bytes of MENU.BA, original, copied directly to the SD card on 
linux.


---

0x0B6

0x080

0x000

0x000

...

MENU.BA copied from SD to M100 via Arduino, then copied from M100 back 
to Linux via dlpus


---

0x140

0x000

0x000

...

But I get the same change when I put a good original copy on linux, and 
then copy it to the M100 using dlplus, and then back to linux in another 
dir by dlplus.


And I get the same change when I start over and copy from linux to M100 
and back with LaddieAlpha.


So, whatever that is, it's not related to SD2TPDD.


There does seem to be something weird with SD2TPDD though (at least my 
hacked-up version).
If I enable debugging to the serial console, reading a file from SD to 
M100 generates traffic that looks questionable.
There's a packet that repeats a bunch of times that looks like it has 
the filename minus the first letter. No idea what that's about. Almost 
looks like it's doing that operation wrong, and TS-DOS is retrying a 
bunch of times before giving up.
The reverse operation, writing the same file from M100 to SD, generated 
far fewer packets, and didn't have any packets that looked like missing 
the first letter of the filename.


Search "###", or "loop()" to skip ahead to each break point or each 
iteration of loop().


The code that generated this is:

https://github.com/bkw777/SD2TPDD/tree/bkw_al32u4

(note, "bkw_al32u4" branch, not master)

With: #define DEBUG 2

###

# Power-On

# if debugging is enabled, it lists all files in all directories

# to the debug console

###

---[ SD2TPDD setup() ]

Opening SD card...OK.

--- printDirectory(root,0) start ---

GAMES/

--- printDirectory(GAMES,1) start ---

SEXFUN.DO 1638

SHUTTL.DO 5312

HEX.DO 2038

A-DUEL.DO 4997

FOXFGT.DO 2855

TSWEEP.BA 3316

TREK.BA 9434

--- printDirectory(GAMES,1) end ---

PGDSGN/

--- printDirectory(PGDSGN,1) start ---

INVIS0.BA 981

MENU.BA 3102

--- printDirectory(PGDSGN,1) end ---

UTIL/

--- printDirectory(UTIL,1) start ---

CO-RUN.DO 1229

SANDR.DO 2048

RUN-CO.DO 400

OHMLAW.BA 2515

OHMLAW.DO 3204

COMM/

--- printDirectory(COMM,2) start ---

RS232/

--- printDirectory(RS232,3) start ---

RS232.DO 1505

--- printDirectory(RS232,3) end ---

--- printDirectory(COMM,2) end ---

DISK/

--- printDirectory(DISK,2) start ---

DVI/

--- printDirectory(DVI,3) start ---

--- printDirectory(DVI,3) end ---

CHPMNK/

--- printDirectory(CHPMNK,3) start ---

--- printDirectory(CHPMNK,3) end ---

TPDD/

--- printDirectory(TPDD,3) start ---

--- printDirectory(TPDD,3) end ---

--- printDirectory(DISK,2) end ---

--- printDirectory(UTIL,1) end ---

DOS100.CO 5791

LOADER.BA 2521

TSTCPY/

--- printDirectory(TSTCPY,1) start ---

MENU.BA 3102

--- printDirectory(TSTCPY,1) end ---

BARCOD/

--- printDirectory(BARCOD,1) start ---

READBC.BA 604

B3OF9.BA 2611

BPLESY.BA 2611

BUPC.BA 2605

--- printDirectory(BARCOD,1) end ---

VT100/

--- printDirectory(VT100,1) start ---

VT100.EXE 51122

DEFKEY.BA 1105

DIRACC.BA 1447

DIRPOK.BA 616

SETUP.BA 1522

SXM.BA 3560

SXMACC.CO 98

SXMDOC.DO 9382

SXMLDR.BA 1051

SXMMRG.DO 550

VT100.CO 3413

VT100D.CO 3565

VTDOC1.DO 13185

VTDOC2.DO 12182

VTDOC3.DO 15410

VTDOC4.DO 15044

VTDOC5.DO 2100

VTLDR.BA 8303

VTSXM.CO 3505

--- printDirectory(VT100,1) end ---

VIEW80/

--- printDirectory(VIEW80,1) start ---

VIEW80.EXE 7797

DRIVER.CO 3867

MEMMGR.BA 1562

README.DO 413

RUN-TV.BA 486

T-VIEW.BA 876

V80-QR.TXT 2747

BKWJNK.DO 860

--- printDirectory(VIEW80,1) end ---

TEENY.DO 5003

TEENY.BA 2521

DDOC.DO 7421

D.BA 4028

TA100.BA 9414

TA100.DO 592

CARD2.DO 0

--- printDirectory(root,0) end ---

loop(): start

##

# Now it's waiting for any activity on serial port RX pin

# at the beginning of loop()

#

# From the M100, save "ABCD.DO" to disk.

##

Re: [M100] Issue with sd2tpdd

[Gary Hammond]

With the code for sd2tpdd from GitHub, the compiler was issuing the warnings 
below. I have gone through and corrected them and the compiler is now happy and 
the randomness in the first 2 characters is less random. They are still garbage 
characters but now they are nearly consistently the same garbage for a given 
file.
For example, for 3 runs of the load/save of the same file, I got the following 
first 2 bytes (hex)
5C 89
97 8A
5C 89
On a different file I got 1B 8A
The compiler warnings were:
184:33: warning: invalid conversion from 'char*' to 'byte* {aka unsigned 
char*}' [-fpermissive]
92:6: note:   initializing argument 1 of 'void clearBuffer(byte*, int)'
253:30: warning: ISO C++ forbids converting a string constant to 'char*' 
[-Wwrite-strings]
379:28: warning: ISO C++ forbids converting a string constant to 'char*' 
[-Wwrite-strings]
473:24: warning: ISO C++ forbids converting a string constant to 'char*' 
[-Wwrite-strings]
498:24: warning: ISO C++ forbids converting a string constant to 'char*' 
[-Wwrite-strings]
522:34: warning: ISO C++ forbids converting a string constant to 'char*' 
[-Wwrite-strings]

The NULL character is still being appended to the end of the file…no luck so 
far chasing that one down.

To help with those who can confirm that they have their board working fine, I 
am using Arduino 1.8.10 for build and upload.
The GitHub page for the source I am using is 
https://github.com/TangentDelta/SD2TPDD in case I am using the wrong one.

I have now tried my 2 slightly suspect AliExpress Arduino Mega clones and 
various combinations of el cheapo SD card readers and shop bought ones. The 
genuine Arduino Mega I ordered from arduino.cc arrived today so have swapped 
out the clones for the genuine article and still no luck.