Return-Path: <denverh2000@gmail.com>
Delivered-To: craig@sbc-85.com
Received: from gator4254.hostgator.com
	by gator4254.hostgator.com with LMTP
	id yJrhJA3gC2TZaQcAcizydQ
	(envelope-from <denverh2000@gmail.com>)
	for <craig@sbc-85.com>; Fri, 10 Mar 2023 19:57:33 -0600
Return-path: <denverh2000@gmail.com>
Envelope-to: craig@sbc-85.com
Delivery-date: Fri, 10 Mar 2023 19:57:33 -0600
Received: from mail-il1-f179.google.com ([209.85.166.179]:45779)
	by gator4254.hostgator.com with esmtps  (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.95)
	(envelope-from <denverh2000@gmail.com>)
	id 1paoUH-0028yq-9J
	for craig@sbc-85.com;
	Fri, 10 Mar 2023 19:57:33 -0600
Received: by mail-il1-f179.google.com with SMTP id x10so4020677ill.12
        for <craig@sbc-85.com>; Fri, 10 Mar 2023 17:57:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112; t=1678499842;
        h=content-transfer-encoding:in-reply-to:mime-version:user-agent:date
         :message-id:from:references:to:subject:from:to:cc:subject:date
         :message-id:reply-to;
        bh=SOrL6ZAE8uYZTZFYy/7CO13eNeYlBNj7rdFVIyIdFVA=;
        b=f74V7dj4ym6IXANuwB48l4IlbJYq68j7Yjo46Ykr4Mt3la0BDBxFV2g1/Tleot64oJ
         fH8nGeWPzBzjDjtOnxs3Ce722WbLqHIeDTUpj4+wPA51XEWcOakUhsEnwS/S6tQcjFOV
         yqGdpe4Jjuli9aDwrhjZz1ZMAsSK2o3ynbrmez5mqTD/wbTM8yBRPajAH7/8mNqitZis
         h8Yy6DSpFMQmwBqOwgOMYdmDHw7J6Jk8mmy7yuTUYwUs+xyRriF0XIJRkBNw0q1WttSS
         VCYWOnrl3k33eq4ElEg93jzsFLtYV7obMd93cLPQQBK/7nvaGnCRBA93U98z8QflfkjW
         23VA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112; t=1678499842;
        h=content-transfer-encoding:in-reply-to:mime-version:user-agent:date
         :message-id:from:references:to:subject:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=SOrL6ZAE8uYZTZFYy/7CO13eNeYlBNj7rdFVIyIdFVA=;
        b=J/II5gMqOhuVu8t4DZgWDDIDc2AETCa155FeUlYsKuGUTUxC2hh5jRtyKOMnhd4d29
         zd/Wxr7p30W0Pzt+yR83iz5g0vcCLfTUvac4VKPP4q4MLvmK2/UchYfXY3rm0wn1884B
         6euLRYURnBx9db59chvhcVAMwS+81B/e1FaThYja8zN/0KF23BbrT+V9BNij1AJq6vRQ
         ZVbxtpSKUn1CfxoBI1HsyMU6+57Q0XVG0jOjv4uwElHU9Bd9s16l8mfflQLQEcLzDzhO
         v5Tarjm3blf41K9T7B3lIxmvJ0DtPF7gMia6p8qSkCUui+5aQhJrv1jt1csxS285joFe
         tR+g==
X-Gm-Message-State: AO0yUKVTks+aNVUAfnBNSFLmcCUwVbGJVsbKTbGOd0Up4ESZLVfyZcw0
	qFR+Y47hajh0+WYZpC+LimD+1E7PAA==
X-Google-Smtp-Source: AK7set+JrbSnd30kFa/I/UWvrLcJ7Hi+3xifcTya2bHFT5SDBaTSOg9OidRU/v4rJsJ+mIRqGwlpQw==
X-Received: by 2002:a05:6e02:1c0e:b0:31c:62a8:9614 with SMTP id l14-20020a056e021c0e00b0031c62a89614mr16925285ilh.28.1678499841983;
        Fri, 10 Mar 2023 17:57:21 -0800 (PST)
Received: from dhbsd.lan ([68.235.43.22])
        by smtp.gmail.com with ESMTPSA id g17-20020a926b11000000b0031559b0cb61sm458129ilc.8.2023.03.10.17.57.20
        for <craig@sbc-85.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Fri, 10 Mar 2023 17:57:21 -0800 (PST)
Subject: Re: TEA % ASM1
To: craig@sbc-85.com
References: <60d6c138-df14-f026-20c6-3ce03d391b5f@gmail.com>
 <6B52D9E9-1713-41CB-8453-A0EAE1747BA2@sbc-85.com>
 <7631ddb3-31e6-1fb0-066d-64b1483ec774@gmail.com>
 <0aff01d953b3$3a539d70$aefad850$@sbc-85.com>
From: denverh <denverh2000@gmail.com>
Message-ID: <3df48822-82cc-3868-6571-7a7d996d5a8c@gmail.com>
Date: Fri, 10 Mar 2023 19:57:19 -0600
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101
 Firefox/68.0 SeaMonkey/2.53.14
MIME-Version: 1.0
In-Reply-To: <0aff01d953b3$3a539d70$aefad850$@sbc-85.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=1.8
X-Spam-Score: 18
X-Spam-Bar: +
X-Spam-Flag: NO

craig@sbc-85.com wrote:
> an interesting thing, I could read in the books but perhaps you can confirm and maybe quickly explain.
>
> when a file is saved from memory using FDOS, its limits and starting address (or some sort of a null if not a program) are included with the file when saved from memory.  but if it is saved using asm1, then you can just specify the file name and no need to include the limits or starting address or if it is a program or text file (e.g., source file).  I presume that tea keeps a running tally of the file length and where it is in memory and if that file is saved directly from the editor using punch, then it appends it with whatever fdos would append for a text file.  if it is saved from ASM1, then it is saved with whatever is equivalent to the G command in fdos.
Ok, this is a little complicated.  All files saved from fdos with "S" 
are organized in data blocks.  Each "L" sub-command creates a separate 
data block.  Each data block starts with a 5 byte header: FF, then the 
address from the "L" sub-command, then the size, calculated from the "L" 
sub-command.  Each block ends with FE.  When you use "G" to finish, it 
writes FE to end the block as usual, then FD to indicate that it's 
executable, then 2 more bytes of start address from the "G" 
sub-command.  If you use "Q", then it ends the block with FE followed by 
FC, which means load only.

When you use the fdos "R" (for run) command to read a file, it will read 
it into the same addresses it originally came from.  If the last data 
block indicates that it's executable, then fdos will jump to the 
indicated address.

For assembled programs, ASM1 follows that format.  However, if you have 
multiple ORG statements, it isn't going to know where the execution 
entry point is.  So, for now, you can really only use a single ORG.  
ASM1 saves that address and uses it as the address for the data block 
header, for calculating the size, and for the execution address at the 
end of the data block.  You can get around the single ORG limitation by 
assembling the program in memory, then exiting to fdos and saving it 
from there.

When saving text files, TEA does not follow the data block format, it 
just saves the file without any additional headers or trailers. That way 
you can read text back into memory using the current TEA buffer area 
without worrying about where that file was when it was originally 
saved.  But you probably won't be able to use the fdos "R" command to 
read it.
>
> I *really* like being able to over write a file directly TEA.  This feature was so unexpected that I spent the morning exiting TEA going to PIP and deleting the source and output files, then back into tea and write the work in memory to MBM, then assemble and write output to MBM.  finally I just tried to save knowing it was already in the MBM and was happy when it asked if I wanted to overwrite.  very nice touch.  that may be in your instructions and I missed it but it was a nice discovery.
Excellent.  Yes, it's too painful to keep switching back and forth 
without that.  I didn't elaborate on that in the instructions, I just 
wrote that if there's an existing file, you have the choice of renaming 
it or deleting it.
>
> is there a way to save the list file from ASM1?  directing to the printer does nothing, right?  and no way to redirect the console to a file.  maybe I have just overlooked that feature.
My Exp85 had a printer port, so that code is mostly still there, but 
disabled.  It's highly unlikely that it would do anything useful anyway, 
so the printer function just returns.  The best way right now would be 
to use whatever capture function your terminal software provides.  If 
you wanted to save the listing to MBM, then that's not something I ever 
had in there.  It could be done, but with a line editor, a printed 
listing is much more useful than having it in a file.
>
> we need to see about getting you a paper tape reader.
Paper tape - oh my.  Maybe I'll do some ebay shopping and see what turns 
up.  I don't even want to think about how long ago it was when I last 
handled paper tape.  But I remember it well.  I can still even remember 
a few bits of the DG bootstrap that you had to toggle in to read the 
paper tape binary loader, which was then used to finally read in 
whatever it was you wanted.

Thanks,

Denver

>
> -----Original Message-----
> From: denverh <denverh2000@gmail.com>
> Sent: Friday, March 10, 2023 2:31 PM
> To: SBC-85 <craig@sbc-85.com>
> Subject: Re: TEA % ASM1
>
> SBC-85 wrote:
>> Hi Denver,
>>
>> Not a big thing, but I wonder if we can keep TEAs punch and read
>> commands as they originally were for tape, and use W(rite) and
>> Something else to write/read from mbm. I still use paper and would
>> eventually like to use the paper tape reader card as an input.  For
>> tape output I use a serial port to the punch (or a TTY).
> Yes, that's certainly possible.  I think all the original reader and punch code is still there, just commented out.  So the MBM functions can be renamed, and two new commands added for MBM I/O.  I don't have a paper tape reader or punch though, but I can look at making a special version that you can try out.  It might be a couple weeks. I have to spend some dreary time on accounting and taxes.
>> Technically, that should be a PIP command.  Or I could just do it
>> separately in additional utilities code above dunfields monitor (where
>> I usually keep my confidence test code)
> Hmm, yes, reader and punch could also be added to PIP.  But I would start with TEA, then add them to ASM1, then PIP.  You'll have to send me some info on ports, registers, etc.  TEA writes data to paper tape in a very specific way.  It splits each byte into two parts, I think.  Plus there are the flags for end of tape, end of file, etc.  And the leader and trailer patterns.  The book has all the details on that.  I never really paid much attention to the subject, not having any equipment.  If you need compatibility with other systems, then that will need to be factored in.
>
> Thanks,
>
> Denver
>
>
>

