3 Dec
2024
3 Dec
'24
8:35 p.m.
They seem to have upgraded the video output!
I found the picture on the front page of this web site
humorous. It's a
place that sells old Jeep parts. Note the computer surfing the web.
https://www.kaiserwillys.com/
4 Dec
4 Dec
4:46 p.m.
On Tue, Dec 3, 2024 at 8:42 PM Fred Cisin via cctalk
<cctalk(a)classiccmp.org> wrote:
They seem to have upgraded the video output!
Is it a CoCo or the Videotex terminal?
The latter was never sold in the UK for obvious reasons, but looking
at the service manual for it, it does seem to have the same video
circuitry as the CoCo.
> I found the picture on the front page of this web site humorous. It's a
> place that sells old Jeep parts. Note the computer surfing the web.
> https://www.kaiserwillys.com/
-tony
4:50 p.m.
What is not well known is that the CoCo was actually designed by
Motorola, and appeared in their Microprocessor data book as a
double-page schematic to promote the 6809!
cheers,
Nigel
On 2024-12-04 11:46, Tony Duell via cctalk wrote:
On Tue, Dec 3, 2024 at 8:42 PM Fred Cisin via cctalk
<cctalk(a)classiccmp.org> wrote:
--
Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU
Amateur Radio, the origin of the open-source concept!
Skype: TILBURY2591
They seem to have upgraded the video output!
Is it a CoCo or the Videotex terminal?
The latter was never sold in the UK for obvious reasons, but looking
at the service manual for it, it does seem to have the same video
circuitry as the CoCo.
> I found the picture on the front page of this web site humorous. It's a
> place that sells old Jeep parts. Note the computer surfing the web.
> https://www.kaiserwillys.com/
-tony
4:55 p.m.
On Wed, Dec 4, 2024 at 4:50 PM Nigel Johnson Ham via cctalk
<cctalk(a)classiccmp.org> wrote:
What is not well known is that the CoCo was actually designed by
Motorola, and appeared in their Microprocessor data book as a
double-page schematic to promote the 6809!
Wasn't it actually a suggested schematic for the 6883 synchronous
address multiplexer chip?
-tony
5:46 p.m.
The story I heard is that Motorola went to Tandy asking them to use
their 6809 chip.
Tandy said, ok, you design a system for us with a cost of $xxx and we
will sell it.
Motorola then designed the color computer using the 6883 SAM chip which
handled almost all of the glue logic for the system. This includes
address decoding, DRAM refresh, system clock, etc.
The CoCo was made up of 3 main chips:
* 6809E CPU (The E used a 2 phase clock so they could alternate cycle
main RAM and video RAM)
* 6883 Synchronous Address Mutiplexor (took care of all of the glue logic)
* 6845 Graphics Controller Chip
Add RAM and a few Misc. chips and discretes and you have a CoCo!
Great machine but no one at Tandy realized the power of the 6809. Maybe
the CoCo III came close to exploiting all that the 6809 could do.
On 12/4/2024 10:55 AM, Tony Duell via cctalk wrote:
On Wed, Dec 4, 2024 at 4:50 PM Nigel Johnson Ham via
cctalk
<cctalk(a)classiccmp.org> wrote:
What is not well known is that the CoCo was
actually designed by
Motorola, and appeared in their Microprocessor data book as a
double-page schematic to promote the 6809!
Wasn't it actually a suggested schematic for the 6883 synchronous
address multiplexer chip?
-tony
5:51 p.m.
On Wed, Dec 4, 2024 at 5:46 PM Mike Katz <bitwiz(a)12bitsbest.com> wrote:
The story I heard is that Motorola went to Tandy asking them to use their 6809 chip.
Tandy said, ok, you design a system for us with a cost of $xxx and we will sell it.
Motorola then designed the color computer using the 6883 SAM chip which handled almost
all of the glue logic for the system. This includes address decoding, DRAM refresh,
system clock, etc.
The CoCo was made up of 3 main chips:
6809E CPU (The E used a 2 phase clock so they could alternate cycle main RAM and video
RAM)
6883 Synchronous Address Mutiplexor (took care of all of the glue logic)
6845 Graphics Controller Chip
Actually a 6847 which is a rather different device
Add RAM and a few Misc. chips and discretes and you have a CoCo!
True.
The schematic in the datasheet I pointed to also shows the ROMs and a
pair of 6821 PIAs as in the CoCo.
Great machine but no one at Tandy realized the power of the 6809. Maybe the CoCo III
came close to exploiting all that the 6809 could do.
Tandy did sell Microware OS-9, BASIC-09. Pascal and C for the CoCo.
That was a rather nice mutliuser OS. I remember at the tme I was
runing OS-9 (initially leval 1 on a 64K CoCo 2, then level 2 on a 512K
CoCo 3) and had to use MS-DOS on a computer at a company I was doing
some work for. The latter felt so primitve by comparison.
-tony
5:53 p.m.
On Wed, Dec 4, 2024 at 5:51 PM Tony Duell <ard.p850ug1(a)gmail.com> wrote:
The schematic in the datasheet I pointed to also shows
the ROMs and a
pair of 6821 PIAs as in the CoCo.
Sorry that never went to the list. The datasheet I refer to is here :
https://archive.org/details/Motorola_MC6883_Synchronous_Address_Multiplexer…
-tony
5:58 p.m.
You are correct. The 6845 was monochrome and the 6847 was the color chip.
If you count a maximum of 16 colors as a color chip🙂. 4 Colors with
artifacting in the highest resolution mode.
On 12/4/2024 11:51 AM, Tony Duell wrote:
On Wed, Dec 4, 2024 at 5:46 PM Mike Katz
<bitwiz(a)12bitsbest.com> wrote:
The story I heard is that Motorola went to Tandy
asking them to use their 6809 chip.
Tandy said, ok, you design a system for us with a cost of $xxx and we will sell it.
Motorola then designed the color computer using the 6883 SAM chip which handled almost
all of the glue logic for the system. This includes address decoding, DRAM refresh,
system clock, etc.
The CoCo was made up of 3 main chips:
6809E CPU (The E used a 2 phase clock so they could alternate cycle main RAM and video
RAM)
6883 Synchronous Address Mutiplexor (took care of all of the glue logic)
6845 Graphics Controller Chip
Actually a 6847 which is a rather different device
Add RAM and a few Misc. chips and discretes and
you have a CoCo!
True.
The schematic in the datasheet I pointed to also shows the ROMs and a
pair of 6821 PIAs as in the CoCo.
Great machine but no one at Tandy realized the
power of the 6809. Maybe the CoCo III came close to exploiting all that the 6809 could
do.
Tandy did sell Microware OS-9, BASIC-09. Pascal and C for the CoCo.
That was a rather nice mutliuser OS. I remember at the tme I was
runing OS-9 (initially leval 1 on a 64K CoCo 2, then level 2 on a 512K
CoCo 3) and had to use MS-DOS on a computer at a company I was doing
some work for. The latter felt so primitve by comparison.
-tony
6:13 p.m.
On Wed, Dec 4, 2024 at 5:58 PM Mike Katz <bitwiz(a)12bitsbest.com> wrote:
You are correct. The 6845 was monochrome and the 6847 was the color chip.
The 6845 was called the 'CRT Controller'. It was basically a set of
programmable counters that would address the video RAM, generate sync
signals, latch the address if a lightpen detected a 'hit' and so on.
It did not do anything with the data from the video RAM, that was
handled by other circuitry. It could certainly be used in colour
systems, the BBC micro, IBM CGA card and so on.
The 6847 was the the video display generator. It could generate the
video addresses and timing (e.g. the Acorn Atom) but didn't have to.
It did handle the data from the video RAM, it had an internal
upper-case only character generator, block graphics, etc. It did
generate colour video.
-tony
6:24 p.m.
Tony,
Thank you for the education. I did some minimal programming of the 6847
on the CoCo and nothing really on the 6845.
A majority of the 6809 programming that I did was for Gimix, when I
worked there in the early 1980's.
And then on embedded 6809 based system, also in the early 1980's.
Mike
On 12/4/2024 12:13 PM, Tony Duell wrote:
On Wed, Dec 4, 2024 at 5:58 PM Mike Katz
<bitwiz(a)12bitsbest.com> wrote:
You are correct. The 6845 was monochrome and the
6847 was the color chip.
The 6845 was called the 'CRT Controller'. It was
basically a set of
programmable counters that would address the video RAM, generate sync
signals, latch the address if a lightpen detected a 'hit' and so on.
It did not do anything with the data from the video RAM, that was
handled by other circuitry. It could certainly be used in colour
systems, the BBC micro, IBM CGA card and so on.
The 6847 was the the video display generator. It could generate the
video addresses and timing (e.g. the Acorn Atom) but didn't have to.
It did handle the data from the video RAM, it had an internal
upper-case only character generator, block graphics, etc. It did
generate colour video.
-tony
6:30 p.m.
On Wed, Dec 4, 2024 at 6:24 PM Mike Katz <bitwiz(a)12bitsbest.com> wrote:
Tony,
Thank you for the education. I did some minimal programming of the 6847
on the CoCo and nothing really on the 6845.
A majority of the 6809 programming that I did was for Gimix, when I
worked there in the early 1980's.
And then on embedded 6809 based system, also in the early 1980's.
In the second half of the 1980s I did a few embedded 6809 projects, my
final year project at university and then some designs a for a company
I did a summer job for. I developped all the code on my CoCo system
under OS-9 and burnt the binaries into EPROMs using a home-made
programmer on the CoCo.
I still have all the hardware, still all works. My Motorola databook
is still on the shelf, although the pages are falling out due to all
the use it has had. Still love the 6809.
-tony
6:49 p.m.
Tony,
I still say the 6809 was the best 8 bit micro ever.
Though I don't have any 6809 systems here I still have my 6809/6809E
Microprocessor Programming Manual from 1981.
Lately I do more with my PDP-8's then anything recent like the 6809🙂
On 12/4/2024 12:30 PM, Tony Duell wrote:
On Wed, Dec 4, 2024 at 6:24 PM Mike Katz
<bitwiz(a)12bitsbest.com> wrote:
Tony,
Thank you for the education. I did some minimal programming of the 6847
on the CoCo and nothing really on the 6845.
A majority of the 6809 programming that I did was for Gimix, when I
worked there in the early 1980's.
And then on embedded 6809 based system, also in the early 1980's.
In the
second half of the 1980s I did a few embedded 6809 projects, my
final year project at university and then some designs a for a company
I did a summer job for. I developped all the code on my CoCo system
under OS-9 and burnt the binaries into EPROMs using a home-made
programmer on the CoCo.
I still have all the hardware, still all works. My Motorola databook
is still on the shelf, although the pages are falling out due to all
the use it has had. Still love the 6809.
-tony
6:53 p.m.
On Wed, Dec 4, 2024 at 6:49 PM Mike Katz <bitwiz(a)12bitsbest.com> wrote:
Tony,
I still say the 6809 was the best 8 bit micro ever.
No dispute from me on that point :-)
Though I don't have any 6809 systems here I still have my 6809/6809E
Microprocessor Programming Manual from 1981.
I still have my CoCos and a Acorn System with a 6809 CPU board in it.
And of course plenty of them in embedded systems -- mosr HP disk or
tape units contain one. So does my HP1630 logic analyser.
Lately I do more with my PDP-8's then anything recent like the 6809🙂
Another elegant processor design.
-tony
7 p.m.
I remember trying to hack the HP9114 3.5" HP-IL floppy drive to handle
two drives in a single enclosure back in the day.
On 12/4/2024 12:53 PM, Tony Duell wrote:
On Wed, Dec 4, 2024 at 6:49 PM Mike Katz
<bitwiz(a)12bitsbest.com> wrote:
Tony,
I still say the 6809 was the best 8 bit micro ever.
No dispute from me on that
point :-)
Though I don't have any 6809 systems here I
still have my 6809/6809E
Microprocessor Programming Manual from 1981.
I still have my CoCos and a Acorn
System with a 6809 CPU board in it.
And of course plenty of them in embedded systems -- mosr HP disk or
tape units contain one. So does my HP1630 logic analyser.
Lately I do more with my PDP-8's then
anything recent like the 6809🙂
Another elegant processor design.
-tony
7:06 p.m.
On 2024-12-04 13:49, Mike Katz via cctalk wrote:
Tony,
I still say the 6809 was the best 8 bit micro ever.
Though I don't have any 6809 systems here I still have my 6809/6809E
Microprocessor Programming Manual from 1981.
Lately I do more with my PDP-8's then anything recent like the 6809🙂
On 12/4/2024 12:30 PM, Tony Duell wrote:
I agree. The user stack pointer was a killer feature. Our repeater
controller controlled, in real time, a 16 x 16 crosspoint matrix
connecting audio and keying from receivers to transmitters, timeout
timers for all RF gear individually, DTMF decode, and separate morse
callsign generation for each transmitter. It could decode on one
channel while it was executing a DTMF command on another. We originally
tried to do his with a 6800 but we needed one more 16-bit register to
achieve real time and the morse sounded like it was being sent by a
duink sailor with his left foot.!
I heard they only discontinued it because the factory burned down, and
never came up with its replacement.
cheers,
Nigel
--
Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU
Amateur Radio, the origin of the open-source concept!
Skype: TILBURY2591
On Wed, Dec 4, 2024 at 6:24 PM Mike Katz
<bitwiz(a)12bitsbest.com> wrote:
Tony,
Thank you for the education. I did some minimal programming of the
6847
on the CoCo and nothing really on the 6845.
A majority of the 6809 programming that I did was for Gimix, when I
worked there in the early 1980's.
And then on embedded 6809 based system, also in the early 1980's.
In the second half of the 1980s I did a few embedded 6809 projects, my
final year project at university and then some designs a for a company
I did a summer job for. I developped all the code on my CoCo system
under OS-9 and burnt the binaries into EPROMs using a home-made
programmer on the CoCo.
I still have all the hardware, still all works. My Motorola databook
is still on the shelf, although the pages are falling out due to all
the use it has had. Still love the 6809.
-tony
7:09 p.m.
On Wed, Dec 4, 2024 at 7:06 PM Nigel Johnson Ham via cctalk
<cctalk(a)classiccmp.org> wrote:
[6809]
I agree. The user stack pointer was a killer feature.
I like(d) the progam counter relative addressing mode along with the
long branch instructions so you could write position-independant code.
-tony
7:14 p.m.
On 2024-12-04 14:09, Tony Duell wrote:
On Wed, Dec 4, 2024 at 7:06 PM Nigel Johnson Ham via
cctalk
<cctalk(a)classiccmp.org> wrote:
[6809]
Yes, a reminder of my pdp-11 days :-)
--
Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU
Amateur Radio, the origin of the open-source concept!
Skype: TILBURY2591
I agree. The user stack pointer was a killer
feature.
I like(d) the progam counter relative addressing mode along with the
long branch instructions so you could write position-independant code.
-tony
7:33 p.m.
On 2024-12-04 12:14 p.m., Nigel Johnson Ham via cctalk wrote:
On 2024-12-04 14:09, Tony Duell wrote:
But that really does not fix code and data relocation.
You need a segment registers for that.
On Wed, Dec 4, 2024 at 7:06 PM Nigel Johnson Ham
via cctalk
<cctalk(a)classiccmp.org> wrote:
[6809]
Yes, a reminder of my pdp-11 days :-)
I agree. The user stack pointer was a killer
feature.
I like(d) the progam counter relative addressing mode along with the
long branch instructions so you could write position-independant code.
-tony
8:19 p.m.
I'm sorry but you don't need segment registers for position independent
code at all.
Address all data off of the index registers or off the PC and all
branches are relative.
You can even have local stack for data using the U stack register.
OS/9 was all relocatable, position independent code. The only addresses
that were absolute in OS/9 were the address of the I/O devices.
OS/9 was a multi tasking, multi user operating system on the 6809. Level
1 ran in 64K, level 2 needed more and used Dynamic Address Translation
to extend the addressing space to 1Mbyte.
On 12/4/2024 1:33 PM, ben via cctalk wrote:
On 2024-12-04 12:14 p.m., Nigel Johnson Ham via cctalk
wrote:
On 2024-12-04 14:09, Tony Duell wrote:
But that really does not fix code and data relocation.
You need a segment registers for that.
On Wed, Dec 4, 2024 at 7:06 PM Nigel Johnson Ham
via cctalk
<cctalk(a)classiccmp.org> wrote:
[6809]
Yes, a reminder of my pdp-11 days :-)
I agree. The user stack pointer was a killer
feature.
I like(d) the progam counter relative addressing mode along with the
long branch instructions so you could write position-independant code.
-tony 
11:08 p.m.
On 12/4/24 14:19, Mike Katz via cctalk wrote:
I'm sorry but you don't need segment registers
for
position independent code at all.
Address all data off of the index registers or off the PC
and all branches are relative.
The PDP-11 had short relative jumps, etc. that were +/- 128
words, so subroutines with small loops, etc. could run
anywhere in memory without rerunning the compiler/assembler.
The IBM 360 had a base register that was used in all memory
references, so the entire object deck (program section, data
section, constants) could be loaded anywhere in memory, then
the base register was set to the beginning of the partition,
and it was all relocatable. However, if the code stored a
physical address at any time (really common in 360 code)
then the program could NOT be moved after it started running.
Jon
5 Dec
5 Dec
2:21 a.m.
The 6809 has an 8 bit Direct Page register. This allows short memory
reference instructions on any 256 byte area in memory.
This would save both program bytes and CPU cycles.
On 12/4/2024 5:08 PM, Jon Elson via cctalk wrote:
On 12/4/24 14:19, Mike Katz via cctalk wrote:
I'm sorry but you don't need segment
registers for position
independent code at all.
Address all data off of the index registers or off the PC and all
branches are relative.
The PDP-11 had short relative jumps, etc. that were +/- 128 words, so
subroutines with small loops, etc. could run anywhere in memory
without rerunning the compiler/assembler.
The IBM 360 had a base register that was used in all memory
references, so the entire object deck (program section, data section,
constants) could be loaded anywhere in memory, then the base register
was set to the beginning of the partition, and it was all
relocatable. However, if the code stored a physical address at any
time (really common in 360 code) then the program could NOT be moved
after it started running.
Jon
4 Dec
4 Dec
8:13 p.m.
I liked the index modes, with accumulator and auto increment/decrement.
The multi-byte push and pop off of the U register for block moves was nice.
And of course the best instruction in the chip was Sign Extend B into
A. That instruction was SEX in the Motorola assembler.
CLR B
SEX
was the same as
CLR A
CLR B
But then you could have sex in your code🙂
Hey, when I was in my 20's and programing the 6809 that was fun.
On 12/4/2024 1:14 PM, Nigel Johnson Ham via cctalk wrote:
On 2024-12-04 14:09, Tony Duell wrote:
On Wed, Dec 4, 2024 at 7:06 PM Nigel Johnson Ham
via cctalk
<cctalk(a)classiccmp.org> wrote:
[6809]
Yes, a reminder of my pdp-11 days :-)
I agree. The user stack pointer was a killer
feature.
I like(d) the progam counter relative addressing mode along with the
long branch instructions so you could write position-independant code.
-tony
8:24 p.m.
On Wed, Dec 4, 2024 at 8:13 PM Mike Katz <bitwiz(a)12bitsbest.com> wrote:
And of course the best instruction in the chip was
Sign Extend B into
A. That instruction was SEX in the Motorola assembler.
CLR B
SEX
was the same as
CLR A
CLR B
But then you could have sex in your code🙂
Hey, when I was in my 20's and programing the 6809 that was fun.
In the UK there was a home computer based on the same Motorola
schematic called the Dragon. Similar to the CoCo, but not identical.
Anyway it was well-known at the time 'You can have SEX with a Dragon'
-tony
10:15 p.m.
This reminded me of an instruction on the Power PC Micro Processor:
Enforce In-Order Execution of I/O with the assembler code of EIEIO
I considered this to be the Old McDonald of instructions.
On 12/4/2024 2:24 PM, Tony Duell wrote:
On Wed, Dec 4, 2024 at 8:13 PM Mike Katz
<bitwiz(a)12bitsbest.com> wrote:
And of course the best instruction in the chip
was Sign Extend B into
A. That instruction was SEX in the Motorola assembler.
CLR B
SEX
was the same as
CLR A
CLR B
But then you could have sex in your code🙂
Hey, when I was in my 20's and programing the 6809 that was fun.
In the UK
there was a home computer based on the same Motorola
schematic called the Dragon. Similar to the CoCo, but not identical.
Anyway it was well-known at the time 'You can have SEX with a Dragon'
-tony 
5 Dec
5 Dec
1:43 a.m.
This reminded me of an instruction on the Power PC
Micro Processor: Enforce
In-Order Execution of I/O with the assembler code of EIEIO
I considered this to be the Old McDonald of instructions.
eieio is a classic, but my favourite new Power ISA instruction is xxlxor (a
vector XOR instruction).
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.com
-- Who ever said the human race was logical? -- Gillian, Star Trek IV ---------
3:59 a.m.
On Wed, Dec 4, 2024 at 10:15 PM Mike Katz <bitwiz(a)12bitsbest.com> wrote:
This reminded me of an instruction on the Power PC Micro Processor:
Enforce In-Order Execution of I/O with the assembler code of EIEIO
I considered this to be the Old McDonald of instructions.
Not an instruction, but the common I/O board in a PERQ2 is the EIO
(Ethernet and Input/Output). There was also OIO (Optional
Input/Output) which provided the 16 bit PERQlink parallel port and a
Canon laser printer interface. Ths led to
'Old McDonald had a PERQ
E-I-O-I-O'
-tony
4 Dec
4 Dec
7:30 p.m.
On 12/4/24 10:49, Mike Katz via cctalk wrote:
I still say the 6809 was the best 8 bit micro ever.
Perhaps, but it was also one of the last new 8-bit CPU designs, so
there's that. The die had already been cast in favor of 16 bit CPUs by
the time of its introduction. And it was far more *expensive* when
compared with other commodity 8-biy CPUs. I recall that by 1984 or so,
the OEM 10K pricing for a Z80A was under a dollar per unit. No way that
the 6809, with a price north of $20 could compete with that.
It was pretty much common knowledge that the 6809 was just a stopgap
product, with a larger, more capable CPU in development due to be
released Real Soon Now. Given the price differential of the 6809
against already established 8 bit CPUs and the specter of obsolescence,
most vendors elected to wait or go with another already-established
8-bit chip.
And then there's the idea that ya dance with the one that brung
ya--which, in many cases was Intel or Zilog.
--Chuck
5 Dec
5 Dec
1:20 p.m.
On Wed, 4 Dec 2024 at 18:56, Mike Katz via cctalk <cctalk(a)classiccmp.org> wrote:
I still say the 6809 was the best 8 bit micro ever.
By "micro" here you mean "microprocessor" rather than the more usual
"microcomputer", yes?
Not being an assembly level programmer, I never cared, but this may
interest 6809 fans:
Arguably the greatest 6502 machine, the Atari XE, with a 6809 brain transplant:
http://liber809.blogspot.com/
https://github.com/boisy/liber809/tree/master/atari
--
Liam Proven ~ Profile: https://about.me/liamproven
Email: lproven(a)cix.co.uk ~ gMail/gTalk/FB: lproven(a)gmail.com
Twitter/LinkedIn: lproven ~ Skype: liamproven
IoM: (+44) 7624 227612: UK: (+44) 7939-087884
Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053
10:43 p.m.
New subject: VT-100 Text Windows library
I am looking for a C library that implements a crude windowing system on
a VT-100 or compatible terminal via the serial port. I've seen such
things before but not recently.
I will be running this on bare metal (no operating system). Preferably
the package would use the regional scrolling capabilities of the VT-100
for faster screen updates.
I might be able to get Txwindows to work but I am looking for something
a bit simpler?
Any ideas would be greatly appreciated.
Thank you....
Mike
11:12 p.m.
New subject: VT-100 Text Windows library
Hello Mike
Isn't ncurses doing what you look for?
Cheers
Gianluca
On Thu, 5 Dec 2024 at 23:01, Mike Katz via cctalk <cctalk(a)classiccmp.org>
wrote:
I am looking for a C library that implements a crude
windowing system on
a VT-100 or compatible terminal via the serial port. I've seen such
things before but not recently.
I will be running this on bare metal (no operating system). Preferably
the package would use the regional scrolling capabilities of the VT-100
for faster screen updates.
I might be able to get Txwindows to work but I am looking for something
a bit simpler?
Any ideas would be greatly appreciated.
Thank you....
Mike
11:16 p.m.
New subject: VT-100 Text Windows library
Under VMS i think the smg$ routines did that.
Sent from my iPhone
On Dec 5, 2024, at 14:43, Mike Katz via cctalk
<cctalk(a)classiccmp.org> wrote:
I am looking for a C library that implements a crude windowing system on a VT-100 or
compatible terminal via the serial port. I've seen such things before but not
recently.
I will be running this on bare metal (no operating system). Preferably the package would
use the regional scrolling capabilities of the VT-100 for faster screen updates.
I might be able to get Txwindows to work but I am looking for something a bit simpler?
Any ideas would be greatly appreciated.
Thank you....
Mike
11:20 p.m.
New subject: VT-100 Text Windows library
Thank you
i don't think an ESP32 has the horsepower to run VMS🙂
On 12/5/2024 5:16 PM, Wayne S wrote:
Under VMS i think the smg$ routines did that.
Sent from my iPhone
> On Dec 5, 2024, at 14:43, Mike Katz via cctalk <cctalk(a)classiccmp.org> wrote:
>
> I am looking for a C library that implements a crude windowing system on a VT-100 or
compatible terminal via the serial port. I've seen such things before but not
recently.
>
> I will be running this on bare metal (no operating system). Preferably the package
would use the regional scrolling capabilities of the VT-100 for faster screen updates.
>
> I might be able to get Txwindows to work but I am looking for something a bit
simpler?
>
> Any ideas would be greatly appreciated.
>
> Thank you....
>
> Mike
11:51 p.m.
New subject: VT-100 Text Windows library
Oh. You didn’t specify the host type, although an esp MAY be fast enough. The Vax wasn’t
that fast to begin with and ran in less than 4 MB memory so maybe…
Sent from my iPhone
On Dec 5, 2024, at 15:20, Mike Katz
<bitwiz(a)12bitsbest.com> wrote:
Thank you
i don't think an ESP32 has the horsepower to run VMS🙂
On 12/5/2024 5:16 PM, Wayne S wrote:
Under VMS i think the smg$ routines did that.
Sent from my iPhone
>> On Dec 5, 2024, at 14:43, Mike Katz via cctalk <cctalk(a)classiccmp.org>
wrote:
>
> I am looking for a C library that implements a crude windowing system on a VT-100 or
compatible terminal via the serial port. I've seen such things before but not
recently.
>
> I will be running this on bare metal (no operating system). Preferably the package
would use the regional scrolling capabilities of the VT-100 for faster screen updates.
>
> I might be able to get Txwindows to work but I am looking for something a bit
simpler?
>
> Any ideas would be greatly appreciated.
>
> Thank you....
>
> Mike
6 Dec
6 Dec
12:31 a.m.
New subject: VT-100 Text Windows library
I'm sorry I thought bare metal (no operating system) was descriptive enough.
To clarify I will be running this on an Doit ESP32 Devkit V1 Board with
a dual core Tensilica Xtensa L6 CPU running at 240 MHz with 4MB Flash
and 520K RAM.
The code is Arduino based (it's not my original code).
On 12/5/2024 5:51 PM, Wayne S wrote:
Oh. You didn’t specify the host type, although an esp
MAY be fast enough. The Vax wasn’t that fast to begin with and ran in less than 4 MB
memory so maybe…
Sent from my iPhone
> On Dec 5, 2024, at 15:20, Mike Katz <bitwiz(a)12bitsbest.com> wrote:
>
> Thank you
>
> i don't think an ESP32 has the horsepower to run VMS🙂
>
>> On 12/5/2024 5:16 PM, Wayne S wrote:
>> Under VMS i think the smg$ routines did that.
>>
>> Sent from my iPhone
>>
>>>> On Dec 5, 2024, at 14:43, Mike Katz via cctalk
<cctalk(a)classiccmp.org> wrote:
>>> I am looking for a C library that implements a crude windowing system on a
VT-100 or compatible terminal via the serial port. I've seen such things before but
not recently.
>>>
>>> I will be running this on bare metal (no operating system). Preferably the
package would use the regional scrolling capabilities of the VT-100 for faster screen
updates.
>>>
>>> I might be able to get Txwindows to work but I am looking for something a bit
simpler?
>>>
>>> Any ideas would be greatly appreciated.
>>>
>>> Thank you....
>>>
>>> Mike
12:41 a.m.
New subject: VT-100 Text Windows library
Yep. I missed the “bare metal”
Sent from my iPhone
On Dec 5, 2024, at 16:31, Mike Katz
<bitwiz(a)12bitsbest.com> wrote:
I'm sorry I thought bare metal (no operating system) was descriptive enough.
To clarify I will be running this on an Doit ESP32 Devkit V1 Board with a dual core
Tensilica Xtensa L6 CPU running at 240 MHz with 4MB Flash and 520K RAM.
The code is Arduino based (it's not my original code).
On 12/5/2024 5:51 PM, Wayne S wrote:
Oh. You didn’t specify the host type, although an esp MAY be fast enough. The Vax wasn’t
that fast to begin with and ran in less than 4 MB memory so maybe…
Sent from my iPhone
>> On Dec 5, 2024, at 15:20, Mike Katz <bitwiz(a)12bitsbest.com> wrote:
>
> Thank you
>
> i don't think an ESP32 has the horsepower to run VMS🙂
>
>> On 12/5/2024 5:16 PM, Wayne S wrote:
>> Under VMS i think the smg$ routines did that.
>>
>> Sent from my iPhone
>>
>>>> On Dec 5, 2024, at 14:43, Mike Katz via cctalk
<cctalk(a)classiccmp.org> wrote:
>>> I am looking for a C library that implements a crude windowing system on a
VT-100 or compatible terminal via the serial port. I've seen such things before but
not recently.
>>>
>>> I will be running this on bare metal (no operating system). Preferably the
package would use the regional scrolling capabilities of the VT-100 for faster screen
updates.
>>>
>>> I might be able to get Txwindows to work but I am looking for something a bit
simpler?
>>>
>>> Any ideas would be greatly appreciated.
>>>
>>> Thank you....
>>>
>>> Mike
2:19 a.m.
New subject: VT-100 Text Windows library
On 12/5/2024 5:51 PM, Wayne S wrote:
> Oh. You didn’t specify the host type, although an esp MAY
> be fast enough. The Vax wasn’t that fast to begin with
> and ran in less than 4 MB memory so maybe…
The first VAX 11/780 I used came with 512 KB of memory. One
Friday afternoon, it crashed and I ran diags and found a
memory board had died, and pulled the bad one out. We had
to run on 256KB over the weekend until DEC could come out
and swap it. It ran a HUGE finite element analysis. I
warned everybody to restrict number of logons and other
processes.
Jon
2:52 a.m.
New subject: VT-100 Text Windows library
On 12/5/2024 9:19 PM, Jon Elson via cctalk wrote:
Your just lucky no one decided to run the Ada compiler. Nothing
can bring a VAX to its knees better than that. Not even Eunice!!
bill
On 12/5/2024 5:51 PM, Wayne S wrote:
> Oh. You didn’t specify the host type, although an esp MAY be fast
> enough. The Vax wasn’t that fast to begin with and ran in less than 4
> MB memory so maybe…
The first VAX 11/780 I used came with 512 KB of memory. One Friday
afternoon, it crashed and I ran diags and found a memory board had died,
and pulled the bad one out. We had to run on 256KB over the weekend
until DEC could come out and swap it. It ran a HUGE finite element
analysis. I warned everybody to restrict number of logons and other
processes.
2:48 a.m.
New subject: VT-100 Text Windows library
On 12/5/2024 6:16 PM, Wayne S via cctalk wrote:
Under VMS i think the smg$ routines did that.
I was going to mention something from the old comp.source.xxx
newsgroup but it would have been for Unix and he specifically
said bare metal.
bill
12:32 a.m.
New subject: VT-100 Text Windows library
On Dec 5, 2024, at 2:43 PM, Mike Katz via cctalk
<cctalk(a)classiccmp.org> wrote:
I am looking for a C library that implements a crude windowing system on a VT-100 or
compatible terminal via the serial port. I've seen such things before but not
recently.
I will be running this on bare metal (no operating system). Preferably the package would
use the regional scrolling capabilities of the VT-100 for faster screen updates.
I might be able to get Txwindows to work but I am looking for something a bit simpler?
Any ideas would be greatly appreciated.
Thank you....
Mike
Screen(1) https://manpages.org/screen could do what you are thinking of.
David
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
David Barto
barto(a)kdbarto.org
1:15 a.m.
New subject: VT-100 Text Windows library
Thank you.
Screen is a linux utility. I am writing this on a bare metal (no
operating system) ESP32 dev board.
Right now the program is text menu driven. I would like to enhance it
with textual windows.
The Txwindows package is perfect but over kill and will need some
hacking to work in my environment and it doesn't support the VT-100's
region scrolling so screen updates might be slow.
On 12/5/2024 6:32 PM, David Barto wrote:
On Dec 5, 2024, at 2:43 PM, Mike Katz via cctalk
<cctalk(a)classiccmp.org> wrote:
I am looking for a C library that implements a crude windowing system
on a VT-100 or compatible terminal via the serial port. I've seen
such things before but not recently.
I will be running this on *bare metal (no operating system)*.
Preferably the package would use the regional scrolling capabilities
of the VT-100 for faster screen updates.
I might be able to get Txwindows to work but I am looking for
something a bit simpler?
Any ideas would be greatly appreciated.
Thank you....
Mike
Screen(1) https://manpages.org/screen could do what you are thinking of.
David
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
David Barto
barto(a)kdbarto.org
10 Dec
10 Dec
2:40 a.m.
New subject: VT-100 Text Windows library
On Thu, 5 Dec 2024 at 20:26, Mike Katz via cctalk <cctalk(a)classiccmp.org>
wrote:
Thank you.
Screen is a linux utility. I am writing this on a bare metal (no
operating system) ESP32 dev board.
Right now the program is text menu driven. I would like to enhance it
with textual windows.
The Txwindows package is perfect but over kill and will need some
hacking to work in my environment and it doesn't support the VT-100's
region scrolling so screen updates might be slow.
What might be helpful is if you could be more specific about what it is
you're trying to achieve. Do you want arbitrarily sized, overlapping
windows or do you just want the screen divided up into discrete segments?
-Henry
1:18 a.m.
New subject: VT-100 Text Windows library
On 12/5/2024 6:32 PM, David Barto via cctalk wrote:
I think the operative sentence in the original request is:
> I will be running this on bare metal (no operating
system). Preferably the package would use the regional scrolling capabilities of the
VT-100 for faster screen updates.
screen and ncurses I believe expect a POSIX subsystem to operate.
Jim
--
Jim Brain
brain(a)jbrain.com
www.jbrain.com
2:03 a.m.
New subject: VT-100 Text Windows library
What about porting the old share-ware window libraries for dos?
2:29 a.m.
New subject: VT-100 Text Windows library
Mike, is the system really without an operating system?
So no cursor control at all?
Sent from my iPhone
On Dec 9, 2024, at 18:03, ben via cctalk
<cctalk(a)classiccmp.org> wrote:
What about porting the old share-ware window libraries for dos?
6 Dec
6 Dec
4:03 a.m.
New subject: VT-100 Text Windows library
Since it's and ESP32 you have, you might look into the screen routines in
http://www.fabglib.org/
"FabGL is mainly a Graphics Library for ESP32. It implements several display drivers
(for direct VGA output and for I2C and SPI LCD drivers).
FabGL can also get input from a PS/2 Keyboard and a Mouse. ULP core handles PS/2 ports
communications, leaving main CPU cores free to perform other tasks.
FabGL also implements: an Audio Engine, a Graphical User Interface (GUI), a Game Engine
and an ANSI/VT Terminal.
This library works with ESP32 revision 1 and upper."
The VT132 emulator board from TheHighNibble uses the FabGL package for it's VT
emulator. It works very well.
--
John H. Reinhardt
On 12/5/2024 4:43 PM, Mike Katz via cctalk wrote:
I am looking for a C library that implements a crude
windowing system on a VT-100 or compatible terminal via the serial port. I've seen
such things before but not recently.
I will be running this on bare metal (no operating system). Preferably the package would
use the regional scrolling capabilities of the VT-100 for faster screen updates.
I might be able to get Txwindows to work but I am looking for something a bit simpler?
Any ideas would be greatly appreciated.
Thank you....
Mike
3:24 p.m.
New subject: VT-100 Text Windows library
Thank you.
This program will allow me to create an ANSII terminal on a graphics
display (LCD or VGA) on an ESP-32.
I will be connected a real live terminal (or terminal emulator) via the
serial port to the ESP-32 and I need the ESP-32 to send ANSI codes to
the terminal to create windows.
Txwindows is a superset of what i am looking for.
On 12/5/2024 10:03 PM, John H. Reinhardt via cctalk wrote:
Since it's and ESP32 you have, you might look into
the screen routines
in http://www.fabglib.org/
"FabGL is mainly a Graphics Library for ESP32. It implements several
display drivers (for direct VGA output and for I2C and SPI LCD drivers).
FabGL can also get input from a PS/2 Keyboard and a Mouse. ULP core
handles PS/2 ports communications, leaving main CPU cores free to
perform other tasks.
FabGL also implements: an Audio Engine, a Graphical User Interface
(GUI), a Game Engine and an ANSI/VT Terminal.
This library works with ESP32 revision 1 and upper."
The VT132 emulator board from TheHighNibble uses the FabGL package for
it's VT emulator. It works very well.
4:05 a.m.
New subject: VT-100 Text Windows library
Since it's and ESP32 you have, you might look into the screen routines in
http://www.fabglib.org/
"FabGL is mainly a Graphics Library for ESP32. It implements several display drivers
(for direct VGA output and for I2C and SPI LCD drivers).
FabGL can also get input from a PS/2 Keyboard and a Mouse. ULP core handles PS/2 ports
communications, leaving main CPU cores free to perform other tasks.
FabGL also implements: an Audio Engine, a Graphical User Interface (GUI), a Game Engine
and an ANSI/VT Terminal.
This library works with ESP32 revision 1 and upper."
The VT132 emulator board from TheHighNibble uses the FabGL package for it's VT
emulator. It works very well.
--
John H. Reinhardt
On 12/5/2024 4:43 PM, Mike Katz via cctalk wrote:
I am looking for a C library that implements a crude
windowing system on a VT-100 or compatible terminal via the serial port. I've seen
such things before but not recently.
I will be running this on bare metal (no operating system). Preferably the package would
use the regional scrolling capabilities of the VT-100 for faster screen updates.
I might be able to get Txwindows to work but I am looking for something a bit simpler?
Any ideas would be greatly appreciated.
Thank you....
Mike
5:47 a.m.
New subject: VT-100 Text Windows library
i tried to remind myself of the details of a terminal multiplexer i used
back in the early 90's. i think i recall it was named 'term', but that
obviously isn't a very useful sesrch term. :)
while looking for it i came across:
https://github.com/deadpixi/mtm
which wilipedia describes as extremely small.
perhaps small enough?
-JimC
--
James Cloos <cloos(a)jhcloos.com>
OpenPGP: https://jhcloos.com/0x997A9F17ED7DAEA6.asc
5 Dec
5 Dec
9:37 p.m.
On Wed, Dec 4, 2024 at 11:55 AM Tony Duell via cctalk
<cctalk(a)classiccmp.org> wrote:
Huh... talk about synchronicity... Minutes ago I collected a packet
from my mailbox with some vintage chips... CDP1802CD, CDP1852, Hitachi
68450, MC6860, and an MC6883.
... and then I see a list thread talking about the MC6883.
Wild.
-ethan
What is not
well known is that the CoCo was actually designed by
Motorola, and appeared in their Microprocessor data book as a
double-page schematic to promote the 6809!
Wasn't it actually a suggested schematic for the 6883 synchronous
address multiplexer chip?
29
days inactive
36
days old
48 comments
18 participants
participants (18)
-
ben -
Bill Gunshannon -
Cameron Kaiser -
Chuck Guzis -
David Barto -
Ethan Dicks -
Fred Cisin -
Gianluca Bonetti -
Henry Bent -
James Cloos -
Jim Brain -
John H. Reinhardt -
Jon Elson -
Liam Proven -
Mike Katz -
Nigel Johnson Ham -
Tony Duell -
Wayne S