Model I vs. Model III
Blake Patterson
Are the display capabilities between the Model I and Model III
identical (assuming no graphics board has been added)?
Is there much software that takes advantage of the 640x240 graphics
board for the III / 4? Of this, is much of it games?
Thanks.
bp
Tom Lake
"Blake Patterson" <blak...@gmail.com> wrote in message
news:a530aace-65e1-4a4e...@b1g2000hsg.googlegroups.com...
> Will Model I software execute, unmodified, on a Model III (or 4)?
>
> Are the display capabilities between the Model I and Model III
> identical (assuming no graphics board has been added)?
Much of it will. Some differences are that the Model I used
memory mapping to access some devices while that was changed
to use I/O ports on the Model III. There are some differences in the
character sets also so some programs designed on the Mod I won't
display properly on the Mod III. One example is the up arrow on the
Mod I displays as a square bracket on the Mod III. If you created
a direction rose on the Mod I it will look strange on the Mod III.
Radio Shack's Casino Games and Invasion Force were affected by this.
This is purely a cosmetic difference, however. The program won't be
affected by it.
Also, the Model III has more ROM than the Model I (I believe it's 14K
as opposed to 12K on a Mod I) so if your program depends on certain
locations in low memory to be free it may not work on the Mod III.
Tom Lake
Knut Roll-Lund
> Also, the Model III has more ROM than the Model I (I believe it's 14K
> as opposed to 12K on a Mod I) so if your program depends on certain
> locations in low memory to be free it may not work on the Mod III.
>
> Tom Lake
>
>
III/4 as compared to Model I.
The extra ROM is in the unused area between the level 2 ROM and the
memory mapped keyboard (i/o). The model III/4 extra ROM contains code
for higspeed cassette ("1500 baud") some keyboard driver stuff and
RS-232 drivers (anyone know? is there a way to enable/use those from
basic?).
The Genie I (model I clone) also has ROM in this area containing a small
debugger and a better keyboard driver.
--
Knut
(delete 'nogarbage.' for email)
Frank Durda IV
: The extra ROM is in the unused area between the level 2 ROM and the
: for higspeed cassette ("1500 baud") some keyboard driver stuff and
: RS-232 drivers (anyone know? is there a way to enable/use those from
: basic?).
"Anyone know" what? You mean, what items are in the "C" ROM?
It's primary function is to house items that are likely to be
hardware model independent, so the cheapest ROM would hopefully be
the only one needing replacement. So frequently the difference between
the US and French or other keyboard models would be only a different
"C" ROM. It didn't always work out that way, but that was the goal.
Most of the entry points for Model III mode (quite a few are in the
"C" ROM or are RAM vectors that point back to the "C" ROM) are
documented in the Model III Hard Disk System documentation, and an
unofficial list is in the LDOS 5.1.x manual set. The RAM hooks also
allowed you to replace the ROM version of a driver with a RAM-based
one, or at least get your hands on requests before passing them on
to the ROM code.
The Model III/4/4D "C"* ROM region is 0x3000 to 0x37FF (2,048 bytes)
contains the following:
* This is included in the larger "D" ROM on gate-array Model 4/4D systems
that absorbed the "B" and "C" ROMs, plus 2K that could be used as
an alternate "C" ROM region, mapped also at 0x3000 to 0x37FF.
1. Entry point table (mainly "C" ROM documented entry points)
2. Hardware initialization, like floppy, interrupt, clock, display (all)
3. Low RAM initialization values, including vectors back into ROM (all)
4. Floppy boot (all)
5. 500 and 1500 baud cassette routines, including "Cass" prompt code,
even though the string itself is in the "A" ROM.
6. Keyboard driver (US, French, German, KANA, others)
7. Network III boot (some educational versions)
8. Network 4 boot (some educational versions)
9. Clock/Time-of-day routines (there were 50Hz and 60Hz versions)
10. RST 38 Interrupt poll routines (all)
11. RS232 driver with initialization, input and output routines (all)
12. KANA Keyboard hooks (most US versions)
13. Daisywheel-II kludge fix-up routine (apparently all)
14. Screen print support (all)
Despite having entry vectors, some routines and even some points
within some routines within the "C"/"D" ROM have to be in exact places
because popular programs were jumping into the middle of things
rather than using the provided vectors, and in a few spots the
one ROM does the same sort of direct reference into one another ROM.
So some of the internal layout is twisted around these requirements.
The XROM/XDROM replacement version re-wrote many of the routines
in the "C" ROM, except for some sections with specific timing
or placement requirements. The original goal was to get more space and
it was enough to have Network III and Network 4 boot, floppy boot
and a hard disk boot (Tandy, Powersoft, or Misosys SCSI) all present
at the same time. (Most of the space came from writing a much
more efficient keyboard driver.) XDROM also included Memory, Video
and Floppy diagnostics accessible via a motherboard option jumper.
Both XROM and XDROM also had room to fix a number of long-standing
bugs or limitations and improved quite a few things, most of which
are only visible when run in Model III mode.
Note also that the Model I naming of ROMs varied by Level I or
Level II, and both were different than the "A" (8K), "B" (4K) and
"C" (2K) of the Model III/4 and the "A" (8K) and "D" (8K) of the
gate-array model 4/4D.
Frank Durda IV - send mail to this address and remove the "LOSE":
<uhclemLOSE.jun08%nemesis.lonestar.org> http://nemesis.lonestar.org
"I'll huff, and I'll puff, and I'll get promoted." - Old Tandy
management saying.
Copyright 2008, ask before reprinting.
Knut Roll-Lund
Thank you for the information!!! I gleaned what I knew from disassembly
of the ROM in my machine (from UK), and I must have missed quite a lot.
I was actually looking for the highspeed cassette stuff. To be a
reference for wav2cas which of course is also much based on the
cassettes I have and the problems I see there. Those wav's I got from
several people also helped to make wav2cas better.
Sorry it wasn't proper English... what I meant was if it was possible to
use the RS-232 drivers with ROM basic and if anyone knew how to enable
and use them. I think neither DOSPLUS nor LDOS make use of these
drivers. I don't know much about the older TRSDOS's, though I have used
TRSDOS 1.3 a little because it came with the model III. Did any of them
use the drivers?
Frank Durda IV
: Thank you for the information!!! I gleaned what I knew from disassembly
: I was actually looking for the highspeed cassette stuff. To be a
: reference for wav2cas which of course is also much based on the
: cassettes I have and the problems I see there. Those wav's I got from
: several people also helped to make wav2cas better.
:
: Sorry it wasn't proper English... what I meant was if it was possible to
: use the RS-232 drivers with ROM basic and if anyone knew how to enable
: and use them. I think neither DOSPLUS nor LDOS make use of these
: drivers. I don't know much about the older TRSDOS's, though I have used
: TRSDOS 1.3 a little because it came with the model III. Did any of them
: use the drivers?
I would have to look over the A/B ROM code and the disk BASIC code to
see if any of it actually references the ROM RS-232 drivers or not, and
check TRSDOS 1.x as well. The locations of the routines are obviously
made available for external use, but whether anyone was actually using
them (other than the Network III boot code), is another question.
Sometimes things got taken out of ROMs during development or out of
early releases for a variety of reasons, leaving other pieces of
now-unreferenced code sitting there, but you were never 100% sure
that some application wasn't relying on it part of that general routine
code, so you might be directed to leave it in.
Although the ROMs supported interrupt-driven functions on RS-232 and
some other devices, when I was writing the XROM/XDROM I came across
what appeared to be a flaw in the original "C" ROM code that would limit
handling of simultaneous interrupts from multiple devices to servicing
only one piece of hardware per interrupt, so if two things triggered an
interrupt condition at the same time, only one would get serviced,
which I would think would have made those routines unreliable. This
may explain why so some operating systems and applications bypass them.
Frank Durda IV - send mail to this address and remove the "LOSE":
<uhclemLOSE.jun08%nemesis.lonestar.org> http://nemesis.lonestar.org
"The Knights who say "LETNi" demand... A SEGMENT REGISTER!!!"
"A what?" "LETNi! LETNi! LETNi!" - 1983
Gary Phillips
One other difference from Mod I to Mod III that I didn't see mentioned
here is in the keyboard map. The two shift keys have different map
locations in the Mod III, while both were the same in the Mod I.
Software for the Mod I that reads the keyboard directly rather than by
calling the ROM routine will fail to recognize one shift key (I'm
pretty sure it was the right shift that was changed.) This was one of
the patches necessary to get the Mod I EDTASM utility working when the
Mod III first came out and didn't yet have it's own assembly language
package available.