> Date: Fri, 8 Feb 2008 01:19:50 -0500
> From: "Golan Klinger"
> Is there something particularly noteworthy about this 64? I see them
> on Craigslist around here quite often and I never thought them worthy of
> mention on this global list.
I don't know a thing about it, but I do know that folks collect them,
so I thought I'd mention it. It holds no interest to me.
Cheers,
Chuck
Hello Mike,
I came across a message from you regarding the manual for a TI-52.
If you still have a PDF for it would you be so kind to mail me a copy?
Regards,
Jos Raven
Holland
mraven at home.nl
jos.raven at gmail.com (for a file lager then 5MB)
(Since the whole point of collecting and restoring old computers is to
demonstrate and *use* them, I hope Jay will find this programming
question on-topic...)
I am currently in the middle of programming some vintage-era MS-DOS
software that has the following requirements:
- Manipulate the speaker to produce arbitrary tones
- Update the screen in arbitrary locations (text mode; multiple screen
pages if available)
- Get single-key input from the user, including sensing keypresses from
"inert" keys like shift and capslock (by themselves as well as in
conjunction with other keypresses)
I know how to do all of that, both high-level (DOS and BIOS calls, ANSI
calls, etc.) and low-level (writing directly to b800:0000, screwing with
the 8253 timer, hooking IRQ 9 and monitoring port 60h, etc.). My
problem is that I'm not sure how much I can "get away" with doing things
low-level and still have it work on machines that were less-than-100%
IBM PC-compatible. If anyone who programmed for early IBM PC
semi-compatible machines from 1981-1985 (Dave? Chuck?), I'd appreciate
any thoughts or advice on what to watch out for. Obviously I'd love to
code it ALL low-level, since that will result in the fastest program
performance for the user, but not if it will lock out 20% or more of all
clones made before 1986.
For example, let's say I go completely low-level, all direct hardware
access, compiling and testing on my IBM 5160 with CGA. Based on my past
experience with clones, I am pretty sure of the following behavior:
- IBM PC 5160: Should work perfectly
- IBM PC 5150: Should work perfectly
- AT&T PC 6300/Olivetti M24: Should work perfectly, although certain key
combinations are known to "stick" without special handling
- Sperry PC: Keyboard scan codes might be different?
- Tandy 1000: Keyboard scan codes differ in 2 or 3 places
- IBM PCjr: Keyboard scan codes are *definitely* different
- DEC Rainbow: Keyboard different? Heard that display was
vector-graphics based; would direct screen writes in text mode even work?
- Tandy 2000: Again, wasn't the screen vector-based?
...etc. That kind of thing.
I guess what I'm asking is something like, "Is it worth attempting to
support 'MS-DOS only' machines made before Compaq, or were they just too
goofy and limited to bother with?" Maybe a follow-up question is, "How
many MS-DOS-only machines were made before 99.9% IBM PC compatibility
became the norm after Compaq's example?"
PS: I'm on a deadline for this project, which is why I care about
wasting time trying to support four different ways of doing the same
thing (like screen access, for example: 1. ansi.sys, 2. DOS calls, 3.
BIOS calls, 4. direct screen writes).
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
> Date: Fri, 08 Feb 2008 01:43:37 +1030
> From: Alexis
> I'm attaching a hard drive to my 8080 computer and there seems to be
> something about the way the sector translation works that's caught my
> attention. Before I go wasting my time trying to figure it out myself I'll
> ask here because there's going to be someone who knows (it's 1:30am and
> I'm feeling a little lazy).
> Another thing is that the total sectors per track in the Disk Parameter
> Block is a 16-bits, not 8-bits.
>
> Apologies if this has been discussed and I've missed it. (Perhaps
> someone can provide a link if it has been)
I'll confine my answer to CP/M 2.2, since that's probably what you're
working with.
There's lots of 16-bit arithmetic in CP/M 2.2--in particular, the 128-
byte block number is maintained as a 16-bit value. This limits the
size of a disk to 65536 128-byte records or 8MB. Yes, you can have a
single track with 65535 sectors on it or 65535 tracks with a a single
sector on each. In theory, the maximum disk size should be about 1GB
(DRM=65535 and BSH=7).
Check it out for yourself in the source at:
http://www.cpm.z80.de/source.html
Note that CP/M 2.2 contains no division routines in its sector and
track computation--the block-to-track-and-sector translation is
handled by repetitive subtraction. There is a little bit of code to
reduce the burden of this by using the last translated block number
to compute the next, though I wonder how many cycles are saved in
practice.
Hope this helps.
Cheers,
Chuck
> Date: Mon, 28 Jan 2008 15:40:04 -0600
> From: Jim Leonard <trixter at oldskool.org>
> - Manipulate the speaker to produce arbitrary tones
> - Update the screen in arbitrary locations (text mode; multiple screen
> pages if available) - Get single-key input from the user, including
> sensing keypresses from "inert" keys like shift and capslock (by
> themselves as well as in conjunction with other keypresses)
It depends on what you want to call "MS-DOS ompatible". NEC 9801
series machines have a completely different I/O port and memory
layout; the CRT controller is a world unto itself and the BIOS
interface is different. But the things run MS-DOS, albeit with 1,024
byte sector diskettes, and have an x86 CPU in them--some with Intel;
others with NEC V-series CPUs. I think the family went as far as a
486 equivalent.
For that matter, I believe a number of configurations of the S-100
Compupro boxes could run MS-DOS.
I know of other MS-DOS compatible machines that do not have memory-
mapped displays but rather interface to a serial terminal (no
graphics capabilities). There are others with non-PC memory layouts
that will give you most of a megabyte of contiguous RAM to work with.
My point is, that "MS-DOS compatible" covers a huge amount of
territory. On the other hand, "something that will boot from a PC-
DOS 3.31 diskette" is quite a bit more restrictive.
FWIW,
Chuck
I was wondering if anybody knows where I could find a copy of this dinosaur.
I know it was written by the ASK group, and later bought by Computer Associates. I want to compile it and fire it up on a pc to show some folks, sort of a technology demo. They have a database on a VAX and are using this as a manufacturing database.
Randy
_________________________________________________________________
Need to know the score, the latest news, or you need your Hotmail?-get your "fix".
http://www.msnmobilefix.com/Default.aspx
>
>Subject: 16-bit sector addresses in CP/M 2.2
> From: Alexis <thrashbarg at kaput.homeunix.org>
> Date: Fri, 08 Feb 2008 01:43:37 +1030
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>Hi,
>
>I'm attaching a hard drive to my 8080 computer and there seems to be
>something about the way the sector translation works that's caught my
>attention. Before I go wasting my time trying to figure it out myself
>I'll ask here because there's going to be someone who knows (it's 1:30am
>and I'm feeling a little lazy).
>
>Observe the following code:
>
>sectran:
> ;translate the sector given by BC using the
> ;translate table given by DE
> xchg ;HL=.trans
> dad b ;HL=.trans(sector)
> mov l,m ;L = trans(sector)
> mvi h,0 ;HL= trans(sector)
> ret ;with value in HL
>
>>From a standard CP/M BIOS.
Firt off that is for for up to 65536 sectors (per track). As that
directly maps to only sectors on a track and only for 128byte logical
sectors. (typically it's less than 64 for most disk drives)
>My question is does the BDOS use this as a 16-bit value, or does it cut
>it to an 8-bit value, like sectran does. H is loaded with 0 and L is
>loaded with the translated sector.
>
>I'm thinking that if this is the case, then a total of 256 tracks *
>65536 sectors * 128 bytes = 2048MB. This could be done without a massive
>translation table by transferring the desired sector, BC, into HL.
It would be that if for only one thing. The math is not way. The
calulation is 65536 sectors total or 65536*128 or 8516608 (8mb).
It's really a result that all math truncates to 16bits.
there are BDOSs that fix this (P2DOS, Suprbdos, Novados, ZRdos...)
and can do the full 2Gb.
>
>I've only just started writing the CBIOS for the hard drive interface
>and I don't really want to waste my time on pointless endeavours.
Define pointless.. The problem is if your using a LBA HD or CF that has
more than 8MB then you have to partition the drive. Also for LBA
addressing there are some track and sector tricks that can be applied
as well for deblocking.
>It wouldn't make sense to use 16-bits for a sector register and 8-bits
>for a track register if you're only going to use 8-bits of the sector
>register, but perhaps the upper 8-bits are used for internal flags or
>error conditions?
You might.
>Another thing is that the total sectors per track in the Disk Parameter
>Block is a 16-bits, not 8-bits.
It allows up to 16bit values for both track and sector. While floppies
never use more than byte values the parameters passed to the BIOS is a
word and it's at your choice to truncate to byte.
Caveat: For floppies and smaller hard disks they are CHS, usually
cylinders needs a byte for floppy but hard disks it may have more than
256 cylinders. Both however rarely have more than 64 logical sectors
per track so a byte works. The gotcga is devices like Ramdisks, CF
and larger IDE drives are or can be LBA where it's easier to look at
it as 1 track of 65536 sectors or 65536 tracks of one sector or anything
that multiples out to 65536! Where the byte/word thing is important
is this case:
Hard disk organized as 16spt (assume they are 128 byte sectors which
rarely happens) and 8192 tracks for 16mb. Thats a total of 131072
sectors. So to use it all you partition it in the bios as two drives
and one has an offset(reseverd tracks) of half the total tracks or 4097.
That means the parameter for tracks passed will be a word as you need
at least 13bits. CP/M does handle that correctly.
It's gets discussed but not often and it's straight forward and not
obvious. The CP/M alteration guide is plain poor on why or how.
the only book that explains this reasonably and you have to read
the whole book to get all the bits is Andy Johnson-Laird, The Programers
CP/M Handbook.
I have done enough things with CP/M and it's bios to have the need to
understand it and that books was both best and good reference. Prior
to that I had to infer, guess and test to see what was really happening.
As a result when I do a bios SETTRACK, and SECSEC stores a word value
and else where I can then selectivly chose to use a byte or word.
Also SECTRAN (AKA skew) is a allways NUL routine in my BIOS as it's
useless when drives that have sectors larger than 128 bytes. For hard
disks and CF/IDE types it's never used as they are too fast. If I need Sectran functionality I do it at the device level rather than have BDOS
do the work. You may use it if you wish and it applies well for any disk that is SD especially for 8"SSSD.
Hope that helps.
Allison
> Are you sure it wasn't an 11/44? I now have that machine, and Mike (who
> said you worked for him) told me that it was the brewhouse supervisory
> machine.
You're right. Have you talked to Mike recently? I haven't seen him for
a couple of years.
> I also got his VAX-11/780
Did you get any of the software collection? He had some very rare stuff.
Sigh.. I can remember the exact layout of the stuff in the PCS basement..
At one time, the 11 and 8 systems were on the second floor. My desk was about
a foot from two RP03 disks.
Hi,
I'm attaching a hard drive to my 8080 computer and there seems to be
something about the way the sector translation works that's caught my
attention. Before I go wasting my time trying to figure it out myself
I'll ask here because there's going to be someone who knows (it's 1:30am
and I'm feeling a little lazy).
Observe the following code:
sectran:
;translate the sector given by BC using the
;translate table given by DE
xchg ;HL=.trans
dad b ;HL=.trans(sector)
mov l,m ;L = trans(sector)
mvi h,0 ;HL= trans(sector)
ret ;with value in HL
>From a standard CP/M BIOS.
My question is does the BDOS use this as a 16-bit value, or does it cut
it to an 8-bit value, like sectran does. H is loaded with 0 and L is
loaded with the translated sector.
I'm thinking that if this is the case, then a total of 256 tracks *
65536 sectors * 128 bytes = 2048MB. This could be done without a massive
translation table by transferring the desired sector, BC, into HL.
I've only just started writing the CBIOS for the hard drive interface
and I don't really want to waste my time on pointless endeavours.
It wouldn't make sense to use 16-bits for a sector register and 8-bits
for a track register if you're only going to use 8-bits of the sector
register, but perhaps the upper 8-bits are used for internal flags or
error conditions?
Another thing is that the total sectors per track in the Disk Parameter
Block is a 16-bits, not 8-bits.
Apologies if this has been discussed and I've missed it. (Perhaps
someone can provide a link if it has been)
Alexis.
