Re: [M100] T200 and the Year

[Brad Grier]

I don't have direct experience with the 200, but if the date is handled the
same way it is on the 100/102/8201a, then it's a ROM thing. An expansion
ROM (like the REX#) or a patched 200 replacement rom should be able to fix
it. Here's an example of how you can patch a NEC PC-8201a ROM.

https://www.web8201.net/default.asp?content=tech.asp

I'm not aware of software solutions...

On Thu, Aug 18, 2022 at 6:57 PM Spencer  wrote:

> Hello!
>
> Can anyone tell me if it's possible to update an issue with the T200 year
> not being able to be set beyond 1999?  I've searched but nothing so far.
>
> Thanks
>


-- 
-- 
Brad

Re: [M100] Another slabtop? Or pc screen extension?

[Jesse Lafleur]

Whoops. Should be fixed in a minute.

On Thu., Aug. 18, 2022, 8:50 p.m. Jeff Gonzales, 
wrote:

> ready100 is website not working it says:Error establishing a database
> connection
>
> On Thu, Aug 18, 2022 at 8:46 PM Jesse Lafleur 
> wrote:
>
>> I still like mine more ;)
>> HTTPS://ready100.com
>>
>> On Thu., Aug. 18, 2022, 5:02 p.m. Ken Pettit,  wrote:
>>
>>> I don't see any teardown videos for it, though from the side view, it
>>> *appears* to have possibility for space.  Though with 5V at 1A current
>>> draw, it would definately drain some batteries!  :-)
>>>
>>> Ken
>>>
>>> On 8/18/22 1:52 PM, John R. Hogerhuis wrote:
>>> > Yeah you're probably right it's purpose built... though I wonder if
>>> > there's any space in there. I mean a raspberry pi as the computer
>>> > would presumably work.
>>>
>>>

Re: [M100] Another slabtop? Or pc screen extension?

[Jeff Gonzales]

ready100 is website not working it says:Error establishing a database
connection

On Thu, Aug 18, 2022 at 8:46 PM Jesse Lafleur  wrote:

> I still like mine more ;)
> HTTPS://ready100.com
>
> On Thu., Aug. 18, 2022, 5:02 p.m. Ken Pettit,  wrote:
>
>> I don't see any teardown videos for it, though from the side view, it
>> *appears* to have possibility for space.  Though with 5V at 1A current
>> draw, it would definately drain some batteries!  :-)
>>
>> Ken
>>
>> On 8/18/22 1:52 PM, John R. Hogerhuis wrote:
>> > Yeah you're probably right it's purpose built... though I wonder if
>> > there's any space in there. I mean a raspberry pi as the computer
>> > would presumably work.
>>
>>

Re: [M100] Another slabtop? Or pc screen extension?

[Jesse Lafleur]

I still like mine more ;)
HTTPS://ready100.com

On Thu., Aug. 18, 2022, 5:02 p.m. Ken Pettit,  wrote:

> I don't see any teardown videos for it, though from the side view, it
> *appears* to have possibility for space.  Though with 5V at 1A current
> draw, it would definately drain some batteries!  :-)
>
> Ken
>
> On 8/18/22 1:52 PM, John R. Hogerhuis wrote:
> > Yeah you're probably right it's purpose built... though I wonder if
> > there's any space in there. I mean a raspberry pi as the computer
> > would presumably work.
>
>

Re: [M100] Another slabtop? Or pc screen extension?

[Ken Pettit]

I don't see any teardown videos for it, though from the side view, it 
*appears* to have possibility for space.  Though with 5V at 1A current 
draw, it would definately drain some batteries!  :-)


Ken

On 8/18/22 1:52 PM, John R. Hogerhuis wrote:
Yeah you're probably right it's purpose built... though I wonder if 
there's any space in there. I mean a raspberry pi as the computer 
would presumably work.

Re: [M100] Another slabtop? Or pc screen extension?

[John R. Hogerhuis]

On Thu, Aug 18, 2022 at 1:37 PM Ken Pettit  wrote:

> Looks super cool, but I'm guessing it has no processor in it and has a
> simple ASIC chip that converts USB to Video / keyscan.  This probably
> removes any possibility of hacking to be a full-fledged computer.
>


Yeah you're probably right it's purpose built... though I wonder if there's
any space in there. I mean a raspberry pi as the computer would presumably
work.

A pi pico would be easier to fit, and people have generated video from it
using the state machine feature.

In any event it seems like there are plenty of these aspect ratio displays
around now.

-- John.

Re: [M100] Another slabtop? Or pc screen extension?

[Ken Pettit]

Looks super cool, but I'm guessing it has no processor in it and has a 
simple ASIC chip that converts USB to Video / keyscan.  This probably 
removes any possibility of hacking to be a full-fledged computer.


Ken

On 8/18/22 1:16 PM, John R. Hogerhuis wrote:

Ain't that pretty?

https://gagadget.com/en/156042-ficihip-mechanical-keyboard-has-an-integrated-126-inch-touchscreen-display/ 



Not sure what it can actually do.

-- John.

Re: [M100] Writing binary files from BASIC

[B 9]

That was a good guess. The NEC documentation actually makes the same
mistake. As you noticed, the snippet I posted calls CHR$(127),  "Back
Space", which is incorrect, but in a later chapter the error gets
compounded:

7. Bad data in DO file
> You cannot store data which include a character whose code is 0, ^X8 or
> ^X1A. The '0' is a 'NULL' to indicate a hole which is not used. Or double
> NULL means the end of the BA file. The ^X8 is 'Back Space'. The ^X1A is
> regarded as the end of the DO file, as you know. Refer to 'DO file'.
>

It seems someone read the word "Back Space" and had the reasonable
conclusion that CHR$(8) was meant. I haven't tested on a NEC PC-8201A, but
at least on my Tandy 200, it is CHR$(127) that is invalid in a DO file.

By the way, I'm rather enjoying reading this documentation which has
surprising moments of charm. Although a technical reference, the authors
occasionally let out a wonderful, youthful enthusiasm for the PC-8201A,
full of so much hope for what people will do in the future with this
incredible machine. From the introduction:

With this manual, may you make super programs for your own purpose !!
>
Mr. Hiroaki Yokoyama, Software Engineer
> Personal Computer Development Division
>

Indeed, Mr. Yokoyama. Even nearly forty years in your future, with your
manual we are making super programs.

—b9

On Thu, Aug 18, 2022 at 11:14 AM Joshua O'Keefe 
wrote:

> > On Aug 18, 2022, at 11:12 AM, Joshua O'Keefe 
> wrote:
> > conjecture, but aren't ^@, ^H, and ^Z control characters that affect
> console output
>
> Apologies for replying to myself; I realize on reflection CHR$(127) is ^?
> (DEL) rather than ^H (BS) isn't it?

[M100] Another slabtop? Or pc screen extension?

[John R. Hogerhuis]

Ain't that pretty?

https://gagadget.com/en/156042-ficihip-mechanical-keyboard-has-an-integrated-126-inch-touchscreen-display/

Not sure what it can actually do.

-- John.

Re: [M100] Writing binary files from BASIC

[Joshua O'Keefe]

> On Aug 18, 2022, at 11:12 AM, Joshua O'Keefe  wrote:
> conjecture, but aren't ^@, ^H, and ^Z control characters that affect console 
> output 

Apologies for replying to myself; I realize on reflection CHR$(127) is ^? (DEL) 
rather than ^H (BS) isn't it?

Re: [M100] Writing binary files from BASIC

[Joshua O'Keefe]

> On Aug 18, 2022, at 10:17 AM, B 9  wrote:
> And you cannot use the 3 Control Characters, NULL (0), Control-Z (26) and 
> Back Space (127).
> 
> While it doesn't explain everything, like what special meaning CHR$(127) has 
> in a DO file,

I'm away from both my systems and documentation, so this is nothing more than 
conjecture, but aren't ^@, ^H, and ^Z control characters that affect console 
output behavior when sent?  Perhaps exceptions are carved out because of their 
relationship to the console output stream.

Re: [M100] Writing binary files from BASIC

[B 9]

Thank you, John.

And thanks for the tip on the NEC technical manual
. It does look
like the best documentation for the Model T! Right away, it explains the
problem that started my whole quest for writing binary files: which bytes
are not allowed in .DO files and why.

The DO file usually consists of the 'ASCII' characters. And you cannot use
> the 3 Control Characters, NULL (0), Control-Z (26) and Back Space (127). (
> 'Control-Z' is sometimes abbreviated as '^Z'.)  Control-Z is used as the
> End of DO file. So if you store it as one of the data in the middle of the
> DO file, the standard programs, BASIC, TEXT and TELCOM will regard that
> Control-Z as the End of that DO file. The data after that Control-Z will
> be lost. Otherwise the NULL is used to fill the hole dug by MAKHOL. After
> copying or inserting the data in to the hole, some routines try to find
> the end of the data by finding the NULL. Then a routine squeezes the NULL
> s. Therefore the NULL in the middle of the DO file might cause serious
> problems. Similarly, the Back Space has special meaning in a DO file.
> Please don't use these three Control characters in a DO file. BASIC's
> PRINT # command cannot save these control characters into DO files.
>

While it doesn't explain everything, like what special meaning CHR$(127)
has in a DO file, it at least tells you about the limitation which is a lot
better than any of the other manuals I have found.

—b9

On Thu, Aug 18, 2022 at 7:54 AM John R. Hogerhuis  wrote:

> Well I think since you're using BASIC you're probably good. I know I've
> seen LNKFIL needing to be called, I don't know the reason.
>
> LNKFIL issue is more likely to originate from 3rd party software since all
> of this stuff was reverse engineered way back when by different people not
> necessarily sharing info or best practices.
>
>
> If you're worried about it you could invoke LNKFIL from your program. But
> SAVEM should do the right thing. If the ROM doesn't do it right, we have
> bigger problems.
>
> By the way the best documention on how the Model T file system works is
> actually in the NEC tech ref/programmers manuals. Very thorough, with
> examples.
>
> -- John.
>

Re: [M100] Writing binary files from BASIC

[John R. Hogerhuis]

Well I think since you're using BASIC you're probably good. I know I've
seen LNKFIL needing to be called, I don't know the reason.

LNKFIL issue is more likely to originate from 3rd party software since all
of this stuff was reverse engineered way back when by different people not
necessarily sharing info or best practices.


If you're worried about it you could invoke LNKFIL from your program. But
SAVEM should do the right thing. If the ROM doesn't do it right, we have
bigger problems.

By the way the best documention on how the Model T file system works is
actually in the NEC tech ref/programmers manuals. Very thorough, with
examples.

-- John.

Re: [M100] Writing binary files from BASIC

[B 9]

Okay, I've written a program which uses the method I proposed above for
first allocating space for a .CO file via *SAVEM* and then POKEing directly
into it. (As opposed to what I believe is the usual method of clearing
space in RAM, poking memory to the RAM buffer, and then saving a copy to a
new .CO file.)

Surprisingly, it works! Or rather, I *think* it works. I haven't blown up
anything on my Tandy 200 (yet).

Can people check my work and tell me if I'm doing something silly before I
release a program that ends up POKEing bytes into the wrong places?

On the Bitchin100 wiki, John mentioned sometimes needing to call the *LNKFIL
*
ROM routine at 2146H in order to fix up the links to the files in the RAM
Directory. I'm imagining one might have an existing .CO file which has to
be resized during *SAVEM*, causing its address in RAM to change. If that
happened and the RAM Directory wasn't updated, it would be disastrous.

However, I believe (and correct me if I'm wrong) that *SAVEM* itself calls
*LNKFIL* on all the different Model T / NEC / Kyocera / Olivetti platforms.
I can see that is true for the Model 100 by looking at Ken Petit's ROM
disassembly
.
(Although, oddly, the comment only mentions line addresses in BASIC
programs.)

For the other variants, I looked to Z88dk's disassembly, although I do not
know how trustworth it is. In particular, I checked the unified disassembly
for the Kyotronic K-85, Olivetti M10, and TRS-80 Model 100
.
While it uses different nomenclature — *RESFPT
*
("reset file pointers") instead of *LNKFIL* — it seems to indicate that,
just like in Ken Petit's M100 disassembly, the K-85 and M10 also reset the
file pointers after saving a .CO file to RAM.  For the NEC PC-8201
,
Z88dk has a disassembly that is not as polished (many of the routines are
named things like "GETWORD_294"), but, again, appears to have *__BSAVE*

calling *RESFPT_0*.

So, at least on the Model 100, K-85, M10, and PC-8201 this method should be
safe. I have not checked the disassembly for the Tandy 102, Tandy 102 UK,
Tandy 200, M10 US, PC-8201A, or PC-8300 — or any of the other Kyocera
Sisters I may have forgotten — but I feel reasonably confident that they
will be derivatives of the source I have already looked at.

What do you all think? This method lets programmers create binary files
without duplicating them first in RAM which means the files can be almost
twice as large. Have I done due diligence in ensuring the technique is
safe? Is there something important I'm missing? (There often is.)

Please let me know. Thanks,

—b9

On Tue, Aug 16, 2022 at 12:34 AM B 9  wrote:

> On Mon, Aug 15, 2022 at 2:04 PM John R. Hogerhuis 
> wrote:
>
>> In fact if you don't CLEAR before load or launch the CO it will fail no
>> matter what, error BEEP and show the Load, Length and EXE address.
>>
>
> The hint about the error BEEP was exactly right.
>
> I just tried SAVEM "FOO.CO", 0, 0 on my Tandy 200 and it created a seven
> byte file which gives an Out of Memory error when LOADMed. Presuming the
> error behaviour is the same on the other platforms, I think setting the
> Load Address to 0 is perfect for preventing people from accidentally
> running a data file as code.
>
>
>
>> I'm trying to avoid duplicating the file in memory. Has anybody ever
>>> tried first creating a .DO file of the correct size in BASIC and then
>>> twiddling the RAM Directory's attribute byte so that it is a binary file?
>>>
>>
>> You cannot do that. The BA, DO and CO regions are separate contiguous
>> blocks. You'd have to move the file bytes if you changed its type. Which is
>> a whole thing.
>>
>
> Thanks for explaining that to me. I'll start with a .CO file.
>
>
>
>> To create a CO file:
>> First,  CLEAR space at some location. [...]
>> After you have a safe area, you can poke your data to it.
>> Then you can SAVE it as a file. This command is different on different
>> BASICs.
>>
>
> Wouldn't clearing space and poking data before creating the file require
> twice as much RAM? Couldn't I do it in reverse?
>
>1. SAVEM "FOO", 0, 16383
>2. Get address of "FOO.CO" from Ram Directory
>3. POKE data directly into RAM
>
> I'm guessing there's a reason people don't do it that way that I'm just
> not seeing.
>
>
> As to having one program run on M100, T200 and NEC... be advised that is
>> tricky if it's even possible. Their BASICs are different, and there ROMs
>> are different and their RAM offsets are different.
>>
>
> Thanks for the warning. I'm hopef