On 10/13/26 23:52, Gary Weber wrote:
Didn't Georg's embedding of Teeny require sacrificing the cassette
routines though? If not, then never mind! Super cool.
I think he just replaced the ADDRSS menu entry with "PIMngr" pointing to
a small routine he wrote where you choose A or S to do ADDRSS or SCHEDL,
and replaced the SCHEDL menu entry with TEENY pointing to teeny
relocated to 7CFB, and his A/S chooser comes after that.
I have added some convenience to my makefile to generate rom-compatible
relocated bin.
Normally by default it generates .CO files with the ORG automatically
calculated to live just below MAXRAM on a 32k machine, and generates a
matching .DO loader.
$ make clean all
The next-most common thing someone might want is an ordinary relocated
.CO just like what some loaders provide at install-time (I don't have a
loader that can do that yet)
So if you want a relocated .CO file you can simply specify HIMEM and get
a .CO that lives just below that.
$ make clean 100na HIMEM=61000
That generates just TEENY_100na.CO and .DO
But if you want to locate it inside of rom space, you probably would
rather just specify ORG instead of some fake HIMEM, and a few other
differences
So now you can also say
make clean M10eu ROM=true ORG=0x7CFB
and that outputs TEENY_M10eu.bin
- ORG at 0x7CFB
- no CO header
- not named .CO because not a .CO
- doesn't try to generate a .DO loader
- the binary doesn't use any self-modifying code
At least for now you're still on your own to hand craft the menu entry
for it.
--
bkw
On Tue, Oct 13, 2026 at 7:15 PM Brian K. White <[email protected]>
wrote:
On 10/13/26 10:12, Gary Weber wrote:
> This is fascinating Brian. At this point you'd be able to embed
your
> refactored Teeny into the 773 bytes that are free (in one block,
even!)
> inside the Olivetti M-10 no-modem (EU) ROM. Heck, even the one
with
> error messages would fit at this point, including the glue code
to set
> up the "Teeny+" launcher in the main menu.
Georg Käter just did exactly that a few days after I made the M-10
EU port.
Look back to Oct 9 for his post.
Super cool. It does make me jealous.
I don't really want to rip out the cassette or bcr code,
regardless how
often they get used. They are part of the machine as it was. When
I play
with old machines, I want the machine to be the best possible old
machine it could have been, not the worst possible new machine you
could
imagine. I would rather think up some actual use for the bcr &
cassette
than break them.
But man built-in tpdd would sure be nice.
Then again, as handy as tpdd is for this specific platform, it's
kind of
only good for that. What I'd really like would be xmodem in
telcom. Even
though it's less convenient, it's more universal. It might be the
*lowest* common denominator, but it's also the *most* common
denominator, if you see what I mean.
With xmodem you could use a 100 to upload a new firmware onto a
serial-only PDU.
But I have no idea how reasonable that is. idk how big an
implimentation
of xmodem would be, and no idea how complicated it would be to add ui
for it into telcom. And in the end of course you would never actually
use it because we have better options now. But I just mean that,
academically, I think the machine just should have that in order
to be a
complete and useful machine. Like it always should have had it as
part
of some minimum baseline feature set that it shouldn't be allowed
to go
below.
--
bkw
> On Tue, Oct 13, 2026 at 6:45 AM Brian K. White
<[email protected]
> <mailto:[email protected]>> wrote:
>
> On 10/10/26 19:53, Brian K. White wrote:
> > On 10/10/26 01:14, Brian K. White wrote:
> >> On 10/9/26 23:02, Brian K. White wrote:
> >>
> >> "It's all the way down to 653 bytes"
> >>
> >> 650!
> >>
> >
> > down to 640, 634 w/o co header
> >
>
> ok that was a bit too far and broke something,
> so it was back up to 644 / 638 for a while
>
> But now down to 632 / 626
>
> So so far
> legacy = 753 bytes
> new = 632 bytes
>
> 121 bytes less than legacy teeny and still exactly the same
> functionality & behavior other than the error messages.
>
> Even with the error codes enabled it's still only 712 bytes,
> and with both error codes and dsr check enabled it's 726 bytes,
> full co file with header.
>
> For something that already started out so small, and was
then worked
> over by Ron Weisen, I'm surprised how much I'm finding that
can be
> rearranged and refactored out.
>
> Besides the error message code there was plain dead or noop code
> too, ie
> code that ran but didn't matter.
> One example is the LOAD routine, while loading a file from
disk to ram,
> it was maintaining a copy of the chunk_progress loop counter
> register in
> ram, (ab)using the packet_type field in the packet buffer to
hold this
> totally unrelated value, and updating it on every byte, for
no reason.
> It was also initializing some stuff twice.
>
> It's really only possible (for me anyway) after massively
fluffing out
> the asm with lots of notes and register state tracing to
track the
> state
> of most of the registers before & after every call/ret/etc.
But only by
> doing that I was able to clear up and correct most of my
earlier tatal
> bafflement comments.
>
> https://github.com/bkw777/dl2/tree/master/clients/teeny/src
> <https://github.com/bkw777/dl2/tree/master/clients/teeny/src>
>
> --
> bkw
>
>
--
bkw
--
bkw
