Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Model 5, build around a Rabbit 3000

10 views
Skip to first unread message

Jan Vanden Bossche

unread,
Apr 16, 2002, 3:52:01 PM4/16/02
to
Hi,

I asked the people from Rabbit Semiconductor a simple question:

Here's the answer:

---quote------------------

Hello Jan,

I am sure that it is possible but it would require a lot of work.

At 08:47 AM 4/15/02 -0700, you wrote:
>Hallo,
>
>Would it be possible to design a microcomputer around the Rabbit 3000 ?
>Featuring disk-drives, IDE-HD, VGA-output and standard-keyboard input ?
>
>I would like to use the operating system LS-DOS 6.x, wich is now freeware.
>
>Greetings from the TyRannoSaurus
>Jan-80

Larry Cicchinelli
Technical Support Manager

Tech Support Bulletin Board: http://www.zworld.com/support/bb/index.html

---end-quote---------------

Owen Robertson

unread,
Apr 17, 2002, 12:29:07 AM4/17/02
to
What's so great about the Rabbit 3000? If we're talking Z-80 software
compatability, what about the Z8000, or better yet, the Z380. I have a PDF
version of the Z380 specs, and it sounds very impressive. And it seems like
it would be fairly easy to design with, too. Internally, it's 32-bit, with a
16-bit data bus, and can handle a 32-bit address space. Hmmm.... LS-DOS 6.x
running with a gigabyte of RAM. :-)

--
Owen Robertson

in article 01c1e4d5$994530a0$LocalHost@amd5x86, Jan Vanden Bossche at
j.vd.b...@pi.be wrote on 4/16/02 2:52 PM:

Amardeep S Chana

unread,
Apr 17, 2002, 7:30:47 AM4/17/02
to
"Owen Robertson" <uni...@earthlink.net> wrote in message
news:B8E264D0.CE60%uni...@earthlink.net...

> What's so great about the Rabbit 3000? If we're talking Z-80 software
> compatability, what about the Z8000, or better yet, the Z380. I have a PDF
> version of the Z380 specs, and it sounds very impressive. And it seems
like
> it would be fairly easy to design with, too. Internally, it's 32-bit, with
a
> 16-bit data bus, and can handle a 32-bit address space. Hmmm.... LS-DOS
6.x
> running with a gigabyte of RAM. :-)
>
> --
> Owen Robertson
>

Z8000 is not Z-80 object code compatible at all. Nor is the Z380 when using
its extended architecture.

Owen Robertson

unread,
Apr 17, 2002, 11:50:39 AM4/17/02
to
in article ubqn7ij...@corp.supernews.com, Amardeep S Chana at
usenet0...@spamgourmet.com wrote on 4/17/02 6:30 AM:

> Z8000 is not Z-80 object code compatible at all. Nor is the Z380 when using
> its extended architecture.

Really? I read on the internet that both of them are. I thought the Z8000
could operate basically as a fast, 16-bit Z80.

--
Owen Robertson

Mark McDougall

unread,
Apr 17, 2002, 8:13:13 PM4/17/02
to
Owen Robertson wrote:

> What's so great about the Rabbit 3000? If we're talking Z-80 software
> compatability, what about the Z8000, or better yet, the Z380. I have a PDF
> version of the Z380 specs, and it sounds very impressive. And it seems like
> it would be fairly easy to design with, too. Internally, it's 32-bit, with a
> 16-bit data bus, and can handle a 32-bit address space. Hmmm.... LS-DOS 6.x
> running with a gigabyte of RAM. :-)


I'm afraid it's not that easy guys... Z80 *object* code designed to run in
64K of RAM is going to require just that - ie. a processor that is running
in native Z80 mode, which also means you're limited to 64K RAM.

Why? Because the Z80 object code in question uses 16-bit registers and
16-bit memory operations for addressing and data accesses - and knows
nothing about larger address spaces and/or banking registers. So you can
forget about running LDOS in 1GB of RAM - if it were possible, you'd be
doing it right now on an emu on your PC!!!

Too bad all the TRS-80 software wasn't written in 'C'...

Regards,

--
--
| Mark McDougall | "Electrical Engineers do it
| <http://members.optushome.com.au/msmcdoug> | with less resistance!"

Owen Robertson

unread,
Apr 17, 2002, 11:57:26 PM4/17/02
to
in article 3CBE0F9...@optushome.com.au, Mark McDougall at
msmc...@optushome.com.au wrote on 4/17/02 7:13 PM:

> I'm afraid it's not that easy guys... Z80 *object* code designed to run in
> 64K of RAM is going to require just that - ie. a processor that is running
> in native Z80 mode, which also means you're limited to 64K RAM.
>
> Why? Because the Z80 object code in question uses 16-bit registers and
> 16-bit memory operations for addressing and data accesses - and knows
> nothing about larger address spaces and/or banking registers.

I was more or less kidding, but, since the matter was pursued, why can't
LS-DOS be modified to support more memory? The OS could stick to the lower
64K, and let user programs have the rest of the space.

--
Owen Robertson

Amardeep S Chana

unread,
Apr 18, 2002, 8:10:57 AM4/18/02
to
"Owen Robertson" <uni...@earthlink.net> wrote in message
news:B8E3048F.CE9C%uni...@earthlink.net...

The Z8000 is an entirely different architecture than the Z80 series. No
compatibility whatsoever there.

The Z380 is object code compatible to Z80 in native (or word) mode only.
You can use added instructions to access the extra memory and I/O ports but
the program counter is limited to 64KB. Not very useful for existing TRS-80
software. In extended mode all operations are 32 bit so even though the
op-codes are still the same they behave in a manner that would prevent Z80
code from running as-is.

Mark McDougall

unread,
Apr 18, 2002, 11:30:14 AM4/18/02
to
Owen Robertson wrote:

> I was more or less kidding, but, since the matter was pursued, why can't
LS-DOS
> be modified to support more memory? The OS could stick to the lower 64K,
> and let user programs have the rest of the space.


When you're running in some sort of 'enhanced mode' (and I don't know much
about the latter Z80 family members) you're simply not going to be able to
execute native Z80 instructions and have them do what they were originally
intended to do.

And as for letting the user programs have the 'rest of the space', again,
you wouldn't be able to execute existing TRS-80 programs that quite simply
expect 16 bits of address space.

I think the closest you'll get is to have some sort of bank-switching
arrangement that allows the OS to sit down low and have user programs
exceute out of banks that are switched in and out by the user. IIRC there
were some homebrew setups and some commercial applications that did just
this on the Model 4 equipped with 128K RAM!?!

Of course, you could write new applications to make use of the newer
architecture, as the existing programs would still 'see' 64K in total, but
then again, why would you bother? Unless I'm mistaken, the original point of
this whole discussion was running original TRS-80 programs on a
super-charged platform?!?

I like the idea of a 'TRS-80 on a chip' myself! Take some grunty SRAM-based
FPGA, implement a Z80 core with some ROM/RAM and have the I/O hanging off
the chip, which could, for example, be interfaced to a PCI bus and have the
screen contents DMA'd to a PC driver every vblank. Ditto for keyboard input.
Disk I/O could be handled in the same way. Or you could hang kbd/video on a
small board housing the chip, with output to modern devices?!?

Regards,

Sylvan Butler

unread,
Apr 18, 2002, 2:47:12 PM4/18/02
to
On Thu, 18 Apr 2002 08:10:57 -0400, Amardeep S Chana <usenet0...@spamgourmet.com> wrote:
> The Z380 is object code compatible to Z80 in native (or word) mode only.

That's all we'd need.

> You can use added instructions to access the extra memory and I/O ports but
> the program counter is limited to 64KB.

Sounds fine.

> Not very useful for existing TRS-80
> software. In extended mode all operations are 32 bit so even though the
> op-codes are still the same they behave in a manner that would prevent Z80
> code from running as-is.

Sounds fine.

Think 8086 to 80[23]86, LIM EMS, etc.

Does it boot up in Z80 mode? if not the boot rom would have to fix
that.

Then all existing software would work as-is. To access extra
memory, the OS could switch to extended mode, copy memory, switch
back. Or else do bank switching like the Model 4. (does it have an
MMU that would support such? If not, it could be added). The added
memory could be used for a ram disk, print spooling, etc. at least.

sdb
--
| Sylvan Butler | Not speaking for Hewlett-Packard | sbutler-boi.hp.com |
| Watch out for my e-mail address. Thank UCE. #### change ^ to @ #### |
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. --Benjamin Franklin, 1759
Fight terrorism, arm the population!

Sylvan Butler

unread,
Apr 18, 2002, 3:48:52 PM4/18/02
to
On Thu, 18 Apr 2002 10:13:13 +1000, Mark McDougall <msmc...@optushome.com.au> wrote:
> I'm afraid it's not that easy guys... Z80 *object* code designed to run in
> 64K of RAM is going to require just that - ie. a processor that is running
> in native Z80 mode, which also means you're limited to 64K RAM.

Right. But there were memory expansion kits and the Model 4
hardware that some applications knew how to access. Could this
new hardware emulate one or both of those?

> Why? Because the Z80 object code in question uses 16-bit registers and
> 16-bit memory operations for addressing and data accesses - and knows
> nothing about larger address spaces and/or banking registers. So you can

Which is exactly why the 8086 used segment registers. That allowed
a machine translation of existing 8080 code. The code would not
have to change, because the loader would simply set up the segment
registers appropriately (even a runtime loader+translator was
envisioned, don't know if it was ever implemented).

Does the Z380 provide some similar capability?

> forget about running LDOS in 1GB of RAM - if it were possible, you'd be
> doing it right now on an emu on your PC!!!

You mean like the bank switching support in XTRS used in Model 4
mode by CP/M (and maybe other software, eg LSDOS, LeScript...)?

Owen Robertson

unread,
Apr 18, 2002, 3:52:40 PM4/18/02
to
in article slrnabu5d7.3lp.Z...@hpb13799Z.Zboi.hpZ.com.invalid,
Sylvan Butler at Znospam+...@hpb13799Z.Zboi.hpZ.com.invalid wrote on
4/18/02 2:48 PM:

> Right. But there were memory expansion kits and the Model 4
> hardware that some applications knew how to access. Could this
> new hardware emulate one or both of those?

I've seen an ad for a kit that expands the memory in a Model 4 to 1MB.
LeScript could access the extra memory. And LDOS might have been able to use
it for certain things, like maybe a RAM disk. Surely there were other
programs that could access the extra memory.

--
Owen Robertson

Amardeep S Chana

unread,
Apr 18, 2002, 6:06:43 PM4/18/02
to
"Sylvan Butler" <Znospam+...@hpb13799Z.Zboi.hpZ.com.invalid> wrote in
message >

> Think 8086 to 80[23]86, LIM EMS, etc.
>
> Does it boot up in Z80 mode? if not the boot rom would have to fix
> that.
>

It does.

> Then all existing software would work as-is. To access extra
> memory, the OS could switch to extended mode, copy memory, switch
> back. Or else do bank switching like the Model 4. (does it have an
> MMU that would support such? If not, it could be added). The added
> memory could be used for a ram disk, print spooling, etc. at least.
>
> sdb

Not quite... I haven't seen any evidence that it supports the undocumented
Z80 opcodes that much TRS-80 software uses.
Besides, production seems to have been discontinued on the '380 family.

Amardeep S Chana

unread,
Apr 18, 2002, 6:09:41 PM4/18/02
to
"Amardeep S Chana" <usenet0...@spamgourmet.com> wrote in message
news:ubugs7...@corp.supernews.com...

Ooops... my mistake. It has not been discontinued. Still listed as active
but it doesn't show up on any of the current product pages at Zilog.

Amardeep S Chana

unread,
Apr 18, 2002, 6:14:14 PM4/18/02
to
"Amardeep S Chana" <usenet0...@spamgourmet.com> wrote in message
> > Besides, production seems to have been discontinued on the '380 family.
> >
> Ooops... my mistake. It has not been discontinued. Still listed as
active
> but it doesn't show up on any of the current product pages at Zilog.
>

I can't seem to get this right... it is in the current product pages, but
not listed as a general purpose microprocessor. It is listed as a
communications controller.

Mo

unread,
Apr 19, 2002, 12:06:03 AM4/19/02
to
This is interesting, in this group the talk is of building a model5, in the
bit.listserv.coco they're talking about building a coco4.
Hmmm...
Mo


Sylvan Butler wrote in message ...

Kelli Halliburton

unread,
Apr 19, 2002, 2:20:02 PM4/19/02
to
"Mo" <mygranny-nospam-@swbell-nospam-.net> wrote in message
news:LIMv8.1590$qT6.60...@newssvr11.news.prodigy.com...

> This is interesting, in this group the talk is of building a model5, in
the
> bit.listserv.coco they're talking about building a coco4.
> Hmmm...
> Mo

What gets me is that, in many ways, the PC architecture is an extension of
the 8080. I mean, the 8086 was intended to be kind of a 16-bit version of
Intel's own 8080 (and the 8088 used in the PC just an "SX" version of the
8086, with an 8-bit data bus instead of 16), and even has a fair amount of
binary compatibility with the 8080.

Now, taking into account that the Z80 had capabilities beyond those of the
8080, there are still enough similarities that CP/M, written for the 8080,
is still useful on the Z80. And there was CP/M-86, and this progression
continued through the current version of DR DOS. (Or didn't everyone know
that it was only a minor tweak to get CP/M to work like MS-DOS? Thanks to
the fact that MS-DOS's origins were based on a quick-and-dirty unauthorized
8086 port of CP/M-80.)

In many ways, the TRS-80 Z80 line did evolve into the PC line. The evolution
simply wasn't by Tandy's hand.

Am I saying that the idea of this project should be abandoned? NO! I'd love
to see a Model 5. People here should be talking to Jeri Ellsworth, who is
currently building the "Commodore One," a sort of uber-64. She has plans to
do similar projects for the early Amiga, and for the Atari 8-bitters. At the
very least, a perusal of the project history would be helpful.

But I'd also be quite interested to see a port of LSDOS for the PC...
complete with a built-in TRS-80 environment emulation, but capable of
utilizing the features of a modern PC as well.

I'd also like to see someone build a case that would allow an ATX
motherboard, a 13-inch monitor, and a small-footprint keyboard to be
integrated, in addition to two full-height (four half-height) 5.25" drive
bays, into one case. Yes, it would be heavy -- but then Model III/4/4P
systems weren't exactly lightweights.


William R. Cousert

unread,
Apr 19, 2002, 4:58:38 PM4/19/02
to

"Kelli Halliburton" <kell...@crosswinds.not> wrote in message
news:mdZv8.5895$Vg4.14...@newssvr17.news.prodigy.com...


I'd like to see a "Tandy One" project, that would combine a next geration
6x09 and z80, and be both Coco and Model 1,3,4 compatible. When in Coco
mode, the Z80 would be used as a co-processor for I/O and vice versa, or it
might be possible to run both modes concurrently if you want. It should have
similar features to the "Commodore One" board.

Tim Mann

unread,
Apr 19, 2002, 10:34:02 PM4/19/02
to
And I'd like to see pigs fly! :-)

--
Tim Mann use...@tim-mann.org http://www.tim-mann.org/

Neil Morrison

unread,
Apr 20, 2002, 2:18:20 PM4/20/02
to
No thanks, pigeon shit is bad enough. You really want the pig population of
W Va flying around your car park?

--

Regards,

Neil

"Tim Mann" <use...@tim-mann.org> wrote in message
news:slrnac1ksq...@giga.mumblefrotz.org...

Ken Walker

unread,
Apr 20, 2002, 11:44:39 PM4/20/02
to
Ever been to a Pink Floyd concert??? (*:

Leonard Erickson

unread,
Apr 22, 2002, 8:03:14 PM4/22/02
to
On Fri, 19 Apr 2002 18:20:02 GMT, "Kelli Halliburton"
<kell...@crosswinds.not> wrote:

>What gets me is that, in many ways, the PC architecture is an extension of
>the 8080. I mean, the 8086 was intended to be kind of a 16-bit version of
>Intel's own 8080 (and the 8088 used in the PC just an "SX" version of the
>8086, with an 8-bit data bus instead of 16), and even has a fair amount of
>binary compatibility with the 8080.

What would have helped is the NEC V-series chip that was going to have a
"native Z-80" mode the way the V20/V30 had an 8080 mode. But it got
postponed and then canceled after Intel filed suit over the V20/V30. :-(

--
Leonard Erickson (aka shadow{G})
sha...@krypton.rain.com <--preferred
leo...@qiclab.scn.rain.com <--last resort

Leonard Erickson

unread,
Apr 22, 2002, 8:09:32 PM4/22/02
to
On Thu, 18 Apr 2002 10:13:13 +1000, Mark McDougall
<msmc...@optushome.com.au> wrote:

>Owen Robertson wrote:
>
>> What's so great about the Rabbit 3000? If we're talking Z-80 software
>> compatability, what about the Z8000, or better yet, the Z380. I have a PDF
>> version of the Z380 specs, and it sounds very impressive. And it seems like
>> it would be fairly easy to design with, too. Internally, it's 32-bit, with a
>> 16-bit data bus, and can handle a 32-bit address space. Hmmm.... LS-DOS 6.x
>> running with a gigabyte of RAM. :-)
>
>
>I'm afraid it's not that easy guys... Z80 *object* code designed to run in
>64K of RAM is going to require just that - ie. a processor that is running
>in native Z80 mode, which also means you're limited to 64K RAM.
>
>Why? Because the Z80 object code in question uses 16-bit registers and
>16-bit memory operations for addressing and data accesses - and knows
>nothing about larger address spaces and/or banking registers. So you can
>forget about running LDOS in 1GB of RAM - if it were possible, you'd be
>doing it right now on an emu on your PC!!!

On the other hand, if we had a processor that had a "virtual Z-80" mode
(much like the 386 and later have virtual-86 mode) then we could run
multiple "sessions" of various TRS-80 software on a system.

And the Model 4 *did* support bank-switched RAM. So with support for
that, you could use a lot of memory. I recall there being 1 meg add-ons
for the Model 4.

>Too bad all the TRS-80 software wasn't written in 'C'...

With proper support at the hardware level, an OS could run as many
"virtual TRS-80" sessions as you had RAM for. And even have Model I, II,
III, 4 and 12 sessions on the same machine.

Model 16/16B/6000 sessions would require a real 680x0 CPU card or some
messy (and slow) emulation.

Leonard Erickson

unread,
Apr 22, 2002, 8:42:21 PM4/22/02
to
On 18 Apr 2002 12:48:52 -0700, Sylvan Butler
<Znospam+...@hpb13799Z.Zboi.hpZ.com.invalid> wrote:

>On Thu, 18 Apr 2002 10:13:13 +1000, Mark McDougall <msmc...@optushome.com.au> wrote:
>> I'm afraid it's not that easy guys... Z80 *object* code designed to run in
>> 64K of RAM is going to require just that - ie. a processor that is running
>> in native Z80 mode, which also means you're limited to 64K RAM.
>
>Right. But there were memory expansion kits and the Model 4
>hardware that some applications knew how to access. Could this
>new hardware emulate one or both of those?

>> Why? Because the Z80 object code in question uses 16-bit registers and
>> 16-bit memory operations for addressing and data accesses - and knows
>> nothing about larger address spaces and/or banking registers. So you can
>
>Which is exactly why the 8086 used segment registers. That allowed
>a machine translation of existing 8080 code. The code would not
>have to change, because the loader would simply set up the segment
>registers appropriately (even a runtime loader+translator was
>envisioned, don't know if it was ever implemented).

Thing is, the opcodes aren't compatible between 8080 and 8086/8088. Just
as one example:

8080 8086/8088
NOP 00h 80h

So you have to have the source code and reassemble or recompile the
code. The binaries aren't compatible.

>> forget about running LDOS in 1GB of RAM - if it were possible, you'd be
>> doing it right now on an emu on your PC!!!
>
>You mean like the bank switching support in XTRS used in Model 4
>mode by CP/M (and maybe other software, eg LSDOS, LeScript...)?

Which had a limit of more like 1 meg.

Leonard Erickson

unread,
Apr 22, 2002, 8:29:52 PM4/22/02
to
On Fri, 19 Apr 2002 01:30:14 +1000, Mark McDougall
<msmc...@optushome.com.au> wrote:

>I think the closest you'll get is to have some sort of bank-switching
>arrangement that allows the OS to sit down low and have user programs
>exceute out of banks that are switched in and out by the user. IIRC there
>were some homebrew setups and some commercial applications that did just
>this on the Model 4 equipped with 128K RAM!?!

Actually, the *stock* Model 4 had some software (Multiplan and Deskmate,
and maybe others) that used the extra RAM via switching pages in and
out.

And there were non-Tandy add-ons that gave up to a meg of RAM.

I'd be happy if I just had the 128k upgrades and hi-res boards for my
Model 4 systems. :-(

>Of course, you could write new applications to make use of the newer
>architecture, as the existing programs would still 'see' 64K in total, but
>then again, why would you bother? Unless I'm mistaken, the original point of
>this whole discussion was running original TRS-80 programs on a
>super-charged platform?!?

As I note, some already *can* use extra RAM. I think the 1 meg limit is
due to the way the bank switching was implemented.

And we'd have to at least patch a lot of programs anyway, simply because
the new CPUs are faster than the originals (50 MHz z-80?)

>I like the idea of a 'TRS-80 on a chip' myself! Take some grunty SRAM-based
>FPGA, implement a Z80 core with some ROM/RAM and have the I/O hanging off
>the chip, which could, for example, be interfaced to a PCI bus and have the
>screen contents DMA'd to a PC driver every vblank. Ditto for keyboard input.
>Disk I/O could be handled in the same way. Or you could hang kbd/video on a
>small board housing the chip, with output to modern devices?!?

I'd rather have a "passive bus" setup with the basic system on a card
and some of the "optional" hardware on other cards. And with "dual"
ports for the various connectors.

So you'd have both PC and TRS-80 style RS-232 connectors, ditto for the
printer port (which would require not merely different connectors, but
different pinouts). And then we get the system bus connector and the
external floppy connector.

Maybe a connector for the old Atari style joysticks that'd emulate the
old Alpha joysticks.

Hmm. Maybe use two "slots" so all the connectors could be on the
backplane of the card. System bus should definitely be on the CPU card.

Heck, I bet we could make the card plug into a PC motherboard! ISA
motherboards are easy to find cheap. And we could have a program on the
PC side that let us change config options on the TRS-80 "coprocessor"
card.

Which would be easier to do for the video? Composite out (which might
not work with the hi-res board outputs), MDA/CGA/EGA type connector? Or
VGA mono output?

For that matter, which floppy controllers do we emulate?

Richard VanHouten

unread,
Apr 22, 2002, 9:25:16 PM4/22/02
to
Leonard Erickson wrote:
>
> On Fri, 19 Apr 2002 01:30:14 +1000, Mark McDougall
> <msmc...@optushome.com.au> wrote:
>
> >I think the closest you'll get is to have some sort of bank-switching
> >arrangement that allows the OS to sit down low and have user programs
> >exceute out of banks that are switched in and out by the user. IIRC there
> >were some homebrew setups and some commercial applications that did just
> >this on the Model 4 equipped with 128K RAM!?!
>
> Actually, the *stock* Model 4 had some software (Multiplan and Deskmate,
> and maybe others) that used the extra RAM via switching pages in and
> out.
>
> And there were non-Tandy add-ons that gave up to a meg of RAM.
>
> I'd be happy if I just had the 128k upgrades and hi-res boards for my
> Model 4 systems. :-(
>
> >Of course, you could write new applications to make use of the newer
> >architecture, as the existing programs would still 'see' 64K in total, but
> >then again, why would you bother? Unless I'm mistaken, the original point of
> >this whole discussion was running original TRS-80 programs on a
> >super-charged platform?!?
>
> As I note, some already *can* use extra RAM. I think the 1 meg limit is
> due to the way the bank switching was implemented.

I think I remember one addon that could give you 2 meg.


>
> And we'd have to at least patch a lot of programs anyway, simply because
> the new CPUs are faster than the originals (50 MHz z-80?)
>
> >I like the idea of a 'TRS-80 on a chip' myself! Take some grunty SRAM-based
> >FPGA, implement a Z80 core with some ROM/RAM and have the I/O hanging off
> >the chip, which could, for example, be interfaced to a PCI bus and have the
> >screen contents DMA'd to a PC driver every vblank. Ditto for keyboard input.
> >Disk I/O could be handled in the same way. Or you could hang kbd/video on a
> >small board housing the chip, with output to modern devices?!?
>
> I'd rather have a "passive bus" setup with the basic system on a card
> and some of the "optional" hardware on other cards. And with "dual"
> ports for the various connectors.
>
> So you'd have both PC and TRS-80 style RS-232 connectors,

??? What's the difference on the 25 pin connector, besides the connector
sex? Or are you saying use the 25 and 9 pine connectors?

> ditto for the
> printer port (which would require not merely different connectors, but
> different pinouts).

If you have a 25 pin RS-232 connector with the same sex as a TRS-80, and
a 25 pin PC-style printer port, you've got potential disaster when
someone plugs a cable in the wrong port.

And then we get the system bus connector and the
> external floppy connector.
>
> Maybe a connector for the old Atari style joysticks that'd emulate the
> old Alpha joysticks.
>
> Hmm. Maybe use two "slots" so all the connectors could be on the
> backplane of the card. System bus should definitely be on the CPU card.
>
> Heck, I bet we could make the card plug into a PC motherboard! ISA
> motherboards are easy to find cheap. And we could have a program on the
> PC side that let us change config options on the TRS-80 "coprocessor"
> card.
>
> Which would be easier to do for the video? Composite out (which might
> not work with the hi-res board outputs), MDA/CGA/EGA type connector? Or
> VGA mono output?
>
> For that matter, which floppy controllers do we emulate?

1793, surely?

Leonard Erickson

unread,
Apr 23, 2002, 2:40:10 AM4/23/02
to
On Mon, 22 Apr 2002 21:25:16 -0400, Richard VanHouten
<ric...@citlink.net> wrote:

>Leonard Erickson wrote:
>>
>> And we'd have to at least patch a lot of programs anyway, simply because
>> the new CPUs are faster than the originals (50 MHz z-80?)
>>
>> >I like the idea of a 'TRS-80 on a chip' myself! Take some grunty SRAM-based
>> >FPGA, implement a Z80 core with some ROM/RAM and have the I/O hanging off
>> >the chip, which could, for example, be interfaced to a PCI bus and have the
>> >screen contents DMA'd to a PC driver every vblank. Ditto for keyboard input.
>> >Disk I/O could be handled in the same way. Or you could hang kbd/video on a
>> >small board housing the chip, with output to modern devices?!?
>>
>> I'd rather have a "passive bus" setup with the basic system on a card
>> and some of the "optional" hardware on other cards. And with "dual"
>> ports for the various connectors.
>>
>> So you'd have both PC and TRS-80 style RS-232 connectors,
>
>??? What's the difference on the 25 pin connector, besides the connector
>sex? Or are you saying use the 25 and 9 pine connectors?

Well, some folks setups may involve stuff with the "wrong" gender
connectors.

>> ditto for the
>> printer port (which would require not merely different connectors, but
>> different pinouts).
>
>If you have a 25 pin RS-232 connector with the same sex as a TRS-80, and
>a 25 pin PC-style printer port, you've got potential disaster when
>someone plugs a cable in the wrong port.

Anybody who wants a Model 5 knows more about hardware than that.

And you can put them in "groups". If the PC printer port is next to the
TRS-80 card edge port and over *here* and the RS-232 connectors are over
*there*, with something else in between, I'd say it minimizes the
chances of problems.

> And then we get the system bus connector and the
>> external floppy connector.
>>
>> Maybe a connector for the old Atari style joysticks that'd emulate the
>> old Alpha joysticks.
>>
>> Hmm. Maybe use two "slots" so all the connectors could be on the
>> backplane of the card. System bus should definitely be on the CPU card.
>>
>> Heck, I bet we could make the card plug into a PC motherboard! ISA
>> motherboards are easy to find cheap. And we could have a program on the
>> PC side that let us change config options on the TRS-80 "coprocessor"
>> card.
>>
>> Which would be easier to do for the video? Composite out (which might
>> not work with the hi-res board outputs), MDA/CGA/EGA type connector? Or
>> VGA mono output?
>>
>> For that matter, which floppy controllers do we emulate?
>
>1793, surely?

I was thinking of not merely a Model 5, but also of boards that act like
a Model I, II, II, etc. For the Model I board you have to worry about
*which* double density card...

Nick Andrew

unread,
May 7, 2002, 6:39:09 AM5/7/02
to
Mark McDougall <msmc...@optushome.com.au> writes:

>When you're running in some sort of 'enhanced mode' (and I don't know much
>about the latter Z80 family members) you're simply not going to be able to
>execute native Z80 instructions and have them do what they were originally
>intended to do.

Bank switching works only so long as the program is well-behaved, e.g.
it uses the memory you give it and nothing else, and it uses the defined
interfaces to the rest of the system (which you can hook into and replace
with your own bank-switch-aware versions if necessary).

>I think the closest you'll get is to have some sort of bank-switching
>arrangement that allows the OS to sit down low and have user programs
>exceute out of banks that are switched in and out by the user. IIRC there
>were some homebrew setups and some commercial applications that did just
>this on the Model 4 equipped with 128K RAM!?!

If you recall I had 256k on my System-80, paged as 256 x 1K pages, which
could be mapped in or out of the 48k "normal memory" address space at
will. I modified Newdos/80's own SYS-file swapper so that all of the
OS files were loaded into memory and merely page-switched into normal
address space as required. I also modified the "system call" function
(whatever it was called) so a program A could execute a program B,
and the system would page A's used pages out of accessible memory
while paging in unused pages for B to use. It all worked really well.

Not as well as xtrs under Linux though :-)

>Of course, you could write new applications to make use of the newer
>architecture, as the existing programs would still 'see' 64K in total, but
>then again, why would you bother? Unless I'm mistaken, the original point of
>this whole discussion was running original TRS-80 programs on a
>super-charged platform?!?

For a start, the programs run so much faster :-)
That's why I gave away my beloved System-80 to Ian Mav.

>I like the idea of a 'TRS-80 on a chip' myself! Take some grunty SRAM-based
>FPGA, implement a Z80 core with some ROM/RAM and have the I/O hanging off
>the chip, which could, for example, be interfaced to a PCI bus and have the
>screen contents DMA'd to a PC driver every vblank. Ditto for keyboard input.
>Disk I/O could be handled in the same way. Or you could hang kbd/video on a
>small board housing the chip, with output to modern devices?!?

It sounds cool. Or how about do a PDA version in software instead, that
would be the PockeTRS.

There's only one thing I really wish for with the emulator, and that's
the ability to use the Unix filesystem natively, i.e. allow applications
to read/write files directly off the filesystem. That would require
modifying Newdos/80 (or your favourite OS) to use the emulator hooks for
all file I/O. It would be nice, but unf I don't have the inclination to
do it myself ... yet.

Nick.
--
Do not send me email copies of postings. Keep it in USENET please.

Mark McDougall

unread,
May 20, 2002, 9:04:00 PM5/20/02
to
Nick Andrew wrote:

> Mark McDougall <msmc...@optushome.com.au> writes:


> It sounds cool. Or how about do a PDA version in software instead, that
> would be the PockeTRS.


I'm surprised there isn't one already!?! You can get MAME and a few other
emulators on the various CE-based PDAs around... I guess there's just no
ex-TS-80 users with the inclination/opportunity to do it...


> There's only one thing I really wish for with the emulator, and that's
> the ability to use the Unix filesystem natively, i.e. allow applications
> to read/write files directly off the filesystem. That would require
> modifying Newdos/80 (or your favourite OS) to use the emulator hooks for
> all file I/O. It would be nice, but unf I don't have the inclination to
> do it myself ... yet.


Hmmm, it might be a little more compilicated than that... you've suddenly
gone from a few 100KB to a few tens of GB and that's a problem when you're
handling directories, file pointers etc - especially in 8-bit asm! Then
again, if you hook in at a fairly high level of the file-handling, you might
get away with it - just thinking how the NEWDOS/80 "dir" command is going to
hook in, for example - you'd have to re-write it entirely methinks ...
interesting...

Tim Mann

unread,
May 22, 2002, 4:13:24 AM5/22/02
to
In article <3CE99D00...@optushome.com.au>, Mark McDougall wrote:

> Nick Andrew wrote:
>> There's only one thing I really wish for with the emulator, and that's
>> the ability to use the Unix filesystem natively, i.e. allow applications
>> to read/write files directly off the filesystem. That would require
>> modifying Newdos/80 (or your favourite OS) to use the emulator hooks for
>> all file I/O. It would be nice, but unf I don't have the inclination to
>> do it myself ... yet.
>
> Hmmm, it might be a little more compilicated than that... you've suddenly
> gone from a few 100KB to a few tens of GB and that's a problem when you're
> handling directories, file pointers etc - especially in 8-bit asm! Then
> again, if you hook in at a fairly high level of the file-handling, you might
> get away with it - just thinking how the NEWDOS/80 "dir" command is going to
> hook in, for example - you'd have to re-write it entirely methinks ...
> interesting...

Here's my thought on how to use the Unix fileystem (sort of) natively:
Put code in the emulator that generates a virual TRSDOS-style disk
image for whatever Unix directory you're currently looking at.

That is, suppose you have a Unix directory with files foo, bar, and
baz. Then the emulator generates a fake TRSDOS directory track in
memory with filenames FOO, BAR, and BAZ. Each one has a directory
entry that points to an appropriately-sized piece of the fake disk
image. The disk image doesn't exist as such; instead, the emulator
remembers the mapping between fake disk sector numbers and (Unix
filename, offset within Unix file) pairs, and it translates
reads/writes to the fake disk into reads/writes of corresponding
pieces of the correct files. You'd also have to note writes of the
end-of-file offset to the fake directory entries and translate those
to setting the Unix end-of-file (ftruncate), as well as creation and
deletion of files in the fake directory.

For maximum capacity, the fake disk should appear to be the largest
size the TRS-80 OS supports, preferably even a hard drive rather than
a floppy. Of course the directory format would then be TRS-80
OS-dependent, as LDOS and NEWDOS made different extensions to the
original TRSDOS directory format. So you'd need code for each, but
most of it would be common.

You'd need a "cd" command that would poke the emulator and tell it to
change the fake hard drive to reflect a different Unix directory.
You'd also have to work out how to translate filenames, since Unix
allows a lot more characters and is case sensitive. I suppose you'd
end up with something rather like the MICROS~T.EXE hack that's used to
map long filenames to MS-DOS programs.

This might be a fun project, but it's more than I have time to take
on. Anyone who wants to pick up the idea, bake it some more, and use
it is welcome to it!

Nick Andrew

unread,
May 22, 2002, 9:26:34 PM5/22/02
to
Mark McDougall <msmc...@optushome.com.au> writes:

>Nick Andrew wrote:

>> There's only one thing I really wish for with the emulator, and that's
>> the ability to use the Unix filesystem natively, i.e. allow applications
>> to read/write files directly off the filesystem. That would require
>> modifying Newdos/80 (or your favourite OS) to use the emulator hooks for
>> all file I/O. It would be nice, but unf I don't have the inclination to
>> do it myself ... yet.


>Hmmm, it might be a little more compilicated than that... you've suddenly
>gone from a few 100KB to a few tens of GB and that's a problem when you're
>handling directories, file pointers etc - especially in 8-bit asm! Then
>again, if you hook in at a fairly high level of the file-handling, you might
>get away with it - just thinking how the NEWDOS/80 "dir" command is going to
>hook in, for example - you'd have to re-write it entirely methinks ...
>interesting...


Exackitally!

Rewrite "dir" and all file handling under the "open file" level. Emulate
the content of FCBs ... probably at the emulator level so the emulator
is aware if the user application is trying to do something "smart",

Also most unix pathnames are too long for applications which were only
designed to handle 8.3 plus an optional drive number ... so add a symlink
command which maps a given unix pathname into an 8.3 filename. Just
use the symlink command for every file you want to access, or give it
a wildcard and allow it to choose "similar" 8.3 filenames for each file
in the wildcard expansion.

This emulation could also be done semi-automatically, for example by
providing a "cd" command, and a "dir" for drive 3 would reference the
current _unix_ directory. Auto filename mapping or only display of
files which meet the 8.3 standard (change dot to slash).

An even more compatible way to do the above without requiring OS
changes in the Z80 would be to map the contents of the current
directory to a disk image on the fly. So when you do "dir" the
Z80 code would try to read the directory sectors; this would hook
into the emulator to build a partial disk image. The emulator hook
would choose which files in the current directory would be mapped,
would choose directory slots for the mapped files to go in, and
based on the length of the files would allocate virtual disk sectors
for the file contents. When the files were read, the emulator would
figure out which unix files were being accessed and return data from
the real files on the fly ... IMHO this is real cool and would
pretty-much eliminate the need for storing data in real .DMK
files.

On the write side, the emulator would have to figure out what the OS
is trying to do (create a new file, rewrite existing file, extend file,
remove file) and act accordingly. This is a heap harder than faking
the contents on the fly for read requests, but the TRS-80 OSs were
very simple, their allocation policies are not going to be rocket
science. To give an example of how all this could be coded:

Z80 code creates a new file INFOCOM/TXT
Emulator writes a directory sector
Emulator hook notices a sector write, does "diff" to find out that a
file is being created, creates a real file of zero length

Z80 code writes new data to open file
Emulator writes random, unallocated directory sectors
Emulator hook realises that it has no idea which file is being written
but it saves the data in a buffer for later use

Z80 code closes the open file
Emulator writes directory sector showing sectors allocated to INFOCOM/TXT
Emulator hook figures out that buffered data belongs to real file
infocom.txt and writes the data to that file.

Simple, eh? Tim, TIM, Pleeeeezzzeee!!! canucanucanucanucanucanupleasewriteit?

Nick.
--
http://www.nick-andrew.net/ http://www.news-admin.org/

Nick Andrew

unread,
May 22, 2002, 9:37:39 PM5/22/02
to
Tim Mann <use...@tim-mann.org> writes:

>Here's my thought on how to use the Unix fileystem (sort of) natively:
>Put code in the emulator that generates a virual TRSDOS-style disk
>image for whatever Unix directory you're currently looking at.

Oooh Oooh! I just independently arrived at exactly the same idea.
I hope you didn't patent it first, one of us could end up paying
exhorbitant license fees!

>That is, suppose you have a Unix directory with files foo, bar, and
>baz. Then the emulator generates a fake TRSDOS directory track in
>memory with filenames FOO, BAR, and BAZ. Each one has a directory
>entry that points to an appropriately-sized piece of the fake disk
>image. The disk image doesn't exist as such; instead, the emulator
>remembers the mapping between fake disk sector numbers and (Unix
>filename, offset within Unix file) pairs, and it translates
>reads/writes to the fake disk into reads/writes of corresponding
>pieces of the correct files. You'd also have to note writes of the
>end-of-file offset to the fake directory entries and translate those
>to setting the Unix end-of-file (ftruncate), as well as creation and
>deletion of files in the fake directory.

>For maximum capacity, the fake disk should appear to be the largest
>size the TRS-80 OS supports, preferably even a hard drive rather than
>a floppy. Of course the directory format would then be TRS-80
>OS-dependent, as LDOS and NEWDOS made different extensions to the
>original TRSDOS directory format. So you'd need code for each, but
>most of it would be common.

>You'd need a "cd" command that would poke the emulator and tell it to
>change the fake hard drive to reflect a different Unix directory.
>You'd also have to work out how to translate filenames, since Unix
>allows a lot more characters and is case sensitive. I suppose you'd
>end up with something rather like the MICROS~T.EXE hack that's used to
>map long filenames to MS-DOS programs.

You da MAN, Tim! I've left your entire message quoted above cause it's
all spot on.

>This might be a fun project, but it's more than I have time to take
>on. Anyone who wants to pick up the idea, bake it some more, and use
>it is welcome to it!

Ok (searches for my free time: nope, the disk is 98% full; maybe some
hotshot will do it eventually).

Where's that pay-for-open-source-development website?

www.sourcexchange.com ... no A record anymore, damn!
www.cosource.com ... apparently dead

Looks like it's time to shoot off an email to Eric S. Raymond!

Richard VanHouten

unread,
May 22, 2002, 11:30:50 PM5/22/02
to
Nick Andrew wrote:

> Where's that pay-for-open-source-development website?
>
> www.sourcexchange.com ... no A record anymore, damn!
> www.cosource.com ... apparently dead

www.sourceforge.com?

Nick Andrew

unread,
May 23, 2002, 6:42:02 AM5/23/02
to
Richard VanHouten <ric...@citlink.net> writes:

>www.sourceforge.com?

sourceforge.net ... collaborative development, but what I was really
thinking of was a place I saw some years ago, where you get to
specify a project, and how much you're willing to pay to the first
person who implements an open source application which meets the
specifications of the project.

0 new messages