chess for zx-81 ?
S Kruger
Hi,
I seem to remember something about a chess program
for the _1K_ zx-81. Is that true ?
--
_____________________________________________________________________
_
(_ |_ _ |_ _ _ |/ _ " _ _ _ Stefan Kruger
_)| (/ | (_| |) |\ | (_| (_| (/ | UWCC Computer Science PtII
| _) Email: scm...@cm.cf.ac.uk
-- Man will survive into eternity, because
he's too stupid to know when he's beaten
Martin M|ller Pedersen
Yes, the listning was in the great magazin: 'Your Computer'.
And it worked !!
I also remember a 1k brickout and a 1k bomb the town town.
Both was in Your Computer.
Darwin O'Connor
>Hi,
> I seem to remember something about a chess program
>for the _1K_ zx-81. Is that true ?
>
I had one that worked on the ZX81 in 16K. There weren't many programs that
didn't need the 16K.
Once we played the ZX81 chess game against an Apple ][ chess game and the
ZX81 won.
We even had a flight simulator for the ZX81, though it had no fancy 3D
graphics, just a horizon line out the window.
--
Darwin O'Connor
doc...@ccu.umanitoba.ca
May the 4th be with you.
Peter Gutmann
> I seem to remember something about a chess program
>for the _1K_ zx-81. Is that true ?
There was a version of Microchess for the 1K Kim, so it wouldn't surprise me.
Peter.
--
pg...@cs.aukuni.ac.nz||p_gu...@cs.aukuni.ac.nz||gutm...@kosmos.wcc.govt.nz
pet...@kcbbs.gen.nz||pe...@nacjack.gen.nz||pe...@phlarnschlorpht.nacjack.gen.nz
(In order of preference - one of 'em's bound to work)
-- Nostalgia isn't what it used to be --
A Myles
tried the 1K version, but one of my friends (what do you mean _my only_...)
said it was quite good (i.e. did not seem completely random).
I've seen a BASIC chess for the TI99 (get that right? Think there
should be a 4 and an A somewhere...) which was only about 200 lines long
and seemingly played a decent game.
Anyone know how these worked? Small pool of standard moves, copy player
strategies, learn some state evaluation function?
Andy
--
He's cute, he's sooooo bright, he lies... Andrew Myles, aj...@ee.edinburgh.ac.uk
Integrated Systems Group (the boys to entertain yoooou) (Caledonia)031 650 5665
-----
Yes, I am into flagellation. My favourite is a Jolly Roger. (oooer, Missus...)
Jim Cheetham
: I seem to remember something about a chess program
: for the _1K_ zx-81. Is that true ?
Oh, I'm glad I don't have to inject any facts into afc ... :-)
I *think* you're correct. Although my poor ZX-81 has lost
the ability to read anything from tape (which means I don't
even get the chance to play 3-D Monster Maze anymore :-( )
I'm *sure* I saw such a beast many moons ago ... even before
the complete Rubik's Cube solution for 16K ZX-81 was
published ...
--
_____ ____ _ _ _
(__ __) o ______ ( __)( )_ ___ ___ _( )_( )_ ___ ______
(____) (_)(_)()(_) (____)(_)_)(__=)(__=) (_)_(_)_)(___)_(_)()(_)
-jim cheetham, International Computers Ltd. ICL BRA01 +44 344 424842 x3121
<j...@vpm.icl.co.uk>,<J.Che...@bra0108.wins.icl.co.uk>,<wum...@spuddy.uucp>
Paul Ducklin
> I seem to remember something about a chess program
>for the _1K_ zx-81. Is that true ?
Sure was. I recall an advert for it [never owned a ZX81 myself],
on a cassette tape -- one side had the game "king's pawn moved";
the other had "queen's pawn moved", or something like that!
In 1K. Gasp.
I had a 6KB chess program for my Acorn Atom which didn't
play badly -- and had completely acceptable graphics, too.
OK, by "not badly" I mean *I* thought it was quite good, which isn't
saying much, but it worked fine. And the Atom also had the
*best* Space Invaders game I've ever seen outside an arcade.
One of my cronies ruined my keyboard desperately chasing a saucer :-)
Paul
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\ Paul Ducklin du...@nuustak.csir.co.za /
/ CSIR Computer Virus Lab + Box 395 + Pretoria + 0001 S Africa \
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Martin Thomas
>Yes, the listning was in the great magazin: 'Your Computer'.
>And it worked !!
I've just dug out part 2 of this article. It's in the January 1983 issue of
'Your Computer'.
--
Martin Thomas +44-0554-770546 | "Man masters nature not by force but by
mar...@llanelli.demon.co.uk | understanding. That is why science has
7037...@CompuServe.com | succeeded where magic has failed: it has
CompuServe: 70374,332 | looked for no spell to cast on nature."
| Jacob Bronowski - Science & Human Values
Bernd Meyer
>In article <1993May27.2...@daimi.aau.dk> tu...@daimi.aau.dk writes:
>>Yes, the listning was in the great magazin: 'Your Computer'.
>>And it worked !!
>I've just dug out part 2 of this article. It's in the January 1983 issue of
>'Your Computer'.
Is there anybody out there who has this listing in electronic form, so as to
distribute it over The Net? I'd sure love to show something on this ZX-81
that I finally got recently...
Bernie
--
We both know that the earth is curved | ro...@umibox.hanse.de
so we can't see the way before us to its end. | or
We walk down this way hand in hand, | b-m...@tu-harburg.dbp.de
and I hope you are still with me behind the horizon | Hamburg, Germany
Alexander Bochmann
AM> I've seen a BASIC chess for the TI99 (get that right? Think there
AM> should be a 4 and an A somewhere...) which was only about 200 lines
AM> long and seemingly played a decent game.
TI99/4 was the one with the rubber keys, I think...
The 99/4a had a "real" keyboard. Don't know if they changed anything apart from
that.
I know the TI Chess cartridge (and I think the cartridges didn't have more room
on them than 16kByte (or maybe 32k)). And that one played quite oke, at least
enough to really surprise some of my teachers at school at that time.
Btw, when talking about the TI, is it possible that the TI Extended Basic was
the first Basic that had the possibility to use SUBroutines instead of GOSUBs?
Including passing parameters to the routine...
/\|ex.
--
a...@traveller.fido.de * FidoNet 2:241/7803 * NeST 90:400/101
Eric Fischer
>TI99/4 was the one with the rubber keys, I think...
More plastic than rubber, I'd say. Genuine rubber was found on the portable
CC-40 and the ill-fated TI-99/2, which was killed off when the bottom fell
out of the 99/4A market.
>The 99/4a had a "real" keyboard. Don't know if they changed anything apart from
>that.
At least two other changes I know of: the TMS-9918 video chip in the 99/4 was
replaced by a TMS-9918A. I'm not sure what difference that makes, but I think
the new chip supported a full-screen bitmap mode. The change in video made a
few less bytes available to BASIC (remember, on the 16k console, all the RAM
belonged to the video chip and the CPU had to ask for it a word at a time!),
making a few programs break. Also, the 99/4 had a calculator mode in ROM
which was eliminated in the 99/4A.
>Btw, when talking about the TI, is it possible that the TI Extended Basic was
>the first Basic that had the possibility to use SUBroutines instead of GOSUBs?
>Including passing parameters to the routine...
Did it really? I don't remember this at all, but it's been so long since I
programmed a TI...
Michael Covington
>
>The 99/4a had a "real" keyboard. Don't know if they changed anything apart from
>that.
They added lower-case letters.
[...]
>Btw, when talking about the TI, is it possible that the TI Extended Basic was
>the first Basic that had the possibility to use SUBroutines instead of GOSUBs?
>Including passing parameters to the routine...
TI BASIC is ANSI BASIC (which is otherwise almost unheard-of).
That's why LET is obligatory in assignment statements, and
proliferation of statement types is not permitted (e.g., instead
of CLS they had CALL CLEAR to clear the screen).
My daughters still use a TI-99/4A every few days.
--
:- Michael A. Covington, Associate Research Scientist : *****
:- Artificial Intelligence Programs mcov...@ai.uga.edu : *********
:- The University of Georgia phone 706 542-0358 : * * *
:- Athens, Georgia 30602-7415 U.S.A. amateur radio N4TMI : ** *** ** <><
Andrew McVeigh
> mar...@llanelli.demon.co.uk (Martin Thomas) writes:
>
> >In article <1993May27.2...@daimi.aau.dk> tu...@daimi.aau.dk writes:
> >>Yes, the listning was in the great magazin: 'Your Computer'.
> >>And it worked !!
>
> >I've just dug out part 2 of this article. It's in the January 1983 issue of
> >'Your Computer'.
>
> Is there anybody out there who has this listing in electronic form, so as to
> distribute it over The Net? I'd sure love to show something on this ZX-81
> that I finally got recently...
>
In a book that I bought *ages* ago, titled (I think)
"21 great games for the ZX81 1k" by Clifford Ramshaw,
the last program of the book was a 1k machine code chess
program that played against the user. I sold the book for
a few cents to a local bookshop about a year ago...
Gee -- that brings back some memories. I remember my friend
had a ZX80. It used to go into fast mode whenever it was
working anything out (the screen would blank) and the only
time you could see anything was when the computer wanted
input. The ram pack stuck out the back and if the computer
so much as wobbled, the whole thing reset... He did have
a machine code listing for an amazing ZX80 game, however,
that managed animation on the screen, but was entirely
flicker free -- it was a version of breakout.
> Bernie
> --
> We both know that the earth is curved | ro...@umibox.hanse.de
> so we can't see the way before us to its end. | or
> We walk down this way hand in hand, | b-m...@tu-harburg.dbp.de
> and I hope you are still with me behind the horizon | Hamburg, Germany
--
--------------------------------------------
Andrew McVeigh
all email to: and...@srsuna.shlrc.mq.edu.au
^^^
Dom the Lemming
: mar...@llanelli.demon.co.uk (Martin Thomas) writes:
: >In article <1993May27.2...@daimi.aau.dk> tu...@daimi.aau.dk writes:
: >>Yes, the listning was in the great magazin: 'Your Computer'.
: >>And it worked !!
: >I've just dug out part 2 of this article. It's in the January 1983 issue of
: >'Your Computer'.
: Is there anybody out there who has this listing in electronic form, so as to
: distribute it over The Net? I'd sure love to show something on this ZX-81
: that I finally got recently...
Speaking of which, there is a reasonable working ZX81 emulator available for the
PC. It is called XTender, and can be ftp'ed from src.doc.ic.ac.uk in the directory
/computing/systems/ibmpc/wsmr-simtel20.army.mil/emulators/xtndr093.zip
Should be on any Simtel mirror site near you, tho'. Have fun playing with it, and
just remember: no more Ram-Pack wobble!!
-Dom
--
___ > "I think I'm in love with a retard!"
<*,*> > "Is he bigger than me?"
[`-'] >----------------------------------------Katie & Boon
-"-"- >Dominic Mitchell is: ma9...@brunel.ac.uk
owl >A mutated fridge with some strange ideas about reality
Frank McConnell
Alexander...@traveller.fido.de (Alexander Bochmann) writes:
>the first Basic that had the possibility to use SUBroutines instead of GOSUBs?
>Including passing parameters to the routine...
No. HP had this capability (specifically, multiline functions with
multiple parameters, a functional return, and local variables -- all
of which could be typed, although I don't remember all of the
available types or any restrictions on use of types in these cases) in
their BASIC/3000 interpreter (and compiler), at least as far back as
1977 (and probably a year or two earlier). It wouldn't surprise me in
the least to find that BASIC/3000 got it from some other HP BASIC,
although I am pretty sure that it was not present on the HP 2000
timeshared BASIC interpreter.
ObMicrosoftFlamage: Folks who don't like the fact that Microsoft is
dominating the PC OS market with mediocre offerings are the new kids
on the block -- back in the late 1970s, I didn't like the fact that
Microsoft was dominating the BASIC market with mediocre offerings.
BASIC/3000 was good (IMNSHO better) stuff. Of course, I'm not sure
it could be made to fit on microcomputers of the day....
-Frank McConnell, not representing the opinions of The Wollongong Group
<fr...@twg.com> "I want my MPE" (w/apologies to Dire Straits)
Charlie Gibbs
(Frank McConnell) writes:
>ObMicrosoftFlamage: Folks who don't like the fact that Microsoft is
>dominating the PC OS market with mediocre offerings are the new kids
>on the block -- back in the late 1970s, I didn't like the fact that
>Microsoft was dominating the BASIC market with mediocre offerings.
Not only that, but they led a whole generation of users (and
programmers too, unfortunately) to misspell "OK" with their damned
"Ok" prompt. I like to pronounce it "awk" to piss them off. :-)
Charli...@mindlink.bc.ca
"I don't find this stuff amusing anymore." -- Paul Simon
Michael Covington
>In article <FRANK.93J...@sundance.twg.com> fr...@twg.com
>(Frank McConnell) writes:
>
>>ObMicrosoftFlamage: Folks who don't like the fact that Microsoft is
>
>programmers too, unfortunately) to misspell "OK" with their damned
>"Ok" prompt. I like to pronounce it "awk" to piss them off. :-)
Good point! It makes no sense to capitalize one of the letters and not
the others. O.K., o.k., okay, OK, maybe even ok. Not Ok (nor oK).
Markus Wandel
>>Microsoft was dominating the BASIC market with mediocre offerings.
>
> Not only that, but they led a whole generation of users (and
>programmers too, unfortunately) to misspell "OK" with their damned
>"Ok" prompt. I like to pronounce it "awk" to piss them off. :-)
AARRGH! Everybody knows (well, every 8-bit Commodore owner knows)
that the ONE TRUE BASIC PROMPT looks like this:
READY.
The period is mandatory, lest you execute the prompt as a command
(easy on an 8-bit Commodore) and have it do 'READ Y' instead of
giving a ?SYNTAX ERROR.
Anyway, what was so mediocre about the 8-bit Microsoft BASIC? It
wasn't fancy but it was just the thing for primitive computers
like the Commodore PET. Calling the old Microsoft BASIC mediocre
is like calling V7 Unix mediocre... maybe primitive compared to the
current stuff but very elegant considering the limitations of the
machines it was meant for.
Markus Wandel
mar...@pinetree.org <-- NOT 'mwa...@bnr.ca', that's a black hole.
Eric S. Raymond
> No. HP had this capability (specifically, multiline functions with
> multiple parameters, a functional return, and local variables -- all
> of which could be typed, although I don't remember all of the
> available types or any restrictions on use of types in these cases) in
> their BASIC/3000 interpreter (and compiler), at least as far back as
> 1977 (and probably a year or two earlier).
Hah. You newbie... ;-)
In 1972, UNIVAC XBASIC for the 1108 already had all these features. It was
the first computer manual I read from cover to cover. It may have been
printed as early as 1968.
--
Eric S. Raymond <e...@snark.thyrsus.com>
Frank McConnell
> No. HP had this capability (specifically, multiline functions with
> multiple parameters, a functional return, and local variables -- all
> of which could be typed, although I don't remember all of the
> available types or any restrictions on use of types in these cases) in
> their BASIC/3000 interpreter (and compiler), at least as far back as
> 1977 (and probably a year or two earlier).
In article <1lgG3W#1wQgL09FMcMD3lMxlB1JbLGX=e...@snark.thyrsus.com> e...@snark.thyrsus.com (Eric S. Raymond) writes:
> Hah. You newbie... ;-)
I keep trying to be a newbie -- I sure felt like I was having a lot more
fun back then!
More from Eric:
> In 1972, UNIVAC XBASIC for the 1108 already had all these features. It was
> the first computer manual I read from cover to cover. It may have been
> printed as early as 1968.
Hmm...thanks for the reminder!
My copy of the XBASIC manual is the third edition, and is copyright
1971. (I may be a newbie, but I try to keep my library well stocked
with curiosities.) From the preface:
XBASIC is an improvement and extension of the BASIC produced
by a group at the University of Maryland. The BASIC project was
supported by grant NsG-398 of the National Aeronautics and Space
Administration, and was described in the University of Maryland
Computer Science Center Technical Report 68-77, September 1968,
entitled "BASIC for the UNIVAC 1108", by George Ohlmacher, Robert
Cassels, Thomas Hall, Brian Stanley, and Alfred Beam. This group,
with the aid of other members of the company, produced the XBASIC
system and this manual for Language and Systems Development, Inc.
So you would appear to be right about the time frame. As for me, I
probably got the manual sometime in the mid-1980s from the University
of Maryland College Park CSC Program Library discard pile. A pity,
because this was well after I had any access to a Univac.
From the manual, XBASIC does seem to support very similar multiline
functions, and so it is obvious that they date well before BASIC/3000.
It's clear from the manual that local storage allocation is not
permitted, and I don't see any evidence that XBASIC understands data
types beyond string and real number (e.g. integer and complex), but
it's definitely got some other things I'd have been drooling over at
the time, like support for strings longer than 255 characters, and
preservation of global state (e.g. variables) when the executing
program terminated in error (one thing Microsoft got right, although
HP's tracing facilities made up for this and educated one on the
importance of forethought....)
-Frank McConnell "I want my MPE" (w/apologies to Dire Straits)
<fr...@twg.com>
Charles Lasner
>
>AARRGH! Everybody knows (well, every 8-bit Commodore owner knows)
>that the ONE TRUE BASIC PROMPT looks like this:
>
>READY.
>
>The period is mandatory, lest you execute the prompt as a command
>(easy on an 8-bit Commodore) and have it do 'READ Y' instead of
>giving a ?SYNTAX ERROR.
Explain to me how a blurb issued *by* a program will get executed as a
command typed *into* a program.
cj "full-duplex" l
Charles Lasner
>> Not only that, but they led a whole generation of users (and
>>programmers too, unfortunately) to misspell "OK" with their damned
>>"Ok" prompt. I like to pronounce it "awk" to piss them off. :-)
>
>Good point! It makes no sense to capitalize one of the letters and not
>the others. O.K., o.k., okay, OK, maybe even ok. Not Ok (nor oK).
And it looks too much like the spec for many motherboards I buy today:
486/33 or 386/40 with 0K (meaning no memory chips installed).
cj "SIMM plugger-in-er" l
Mika Iisakkila
>Explain to me how a blurb issued *by* a program will get executed as a
>command typed *into* a program.
On Commode machines you press cursor up and return. That's screen
editing ya know. (disclaimer: I never owned one)
--
Segmented Memory Helps Structure Software
Peter da Silva
> >The period is mandatory, lest you execute the prompt as a command
> >(easy on an 8-bit Commodore) and have it do 'READ Y' instead of
> >giving a ?SYNTAX ERROR.
> Explain to me how a blurb issued *by* a program will get executed as a
> command typed *into* a program.
Atari 800 and Commodore 64 had a cute "screen editor". You listed your program
to the screen, edited it with the cursor keys, cursored to the home position,
and hit "return" repeatedly. It turns out the command line editing worked
right on what was in screen memory, so it didn't care if you'd typed that stuff
or it had printed it.
On the Apple-II you actually had to cursor over the characters, but you could
insert by manually entering VT52 escape sequences (ESC A, ESC B, etc) an
typing stuff out of sequence. You could also expand a line by listing it,
cramming extra text between the expansion of the tokenized output, and list
it again. It'd retokenize so the line would get a bit longer with the new
expanded spaces.
--
Peter da Silva. <pe...@sugar.neosoft.com>.
`-_-' Har du kramat din varg idag?
'U`
"Det er min ledsager, det er ikke drikkepenge."
OS/2 addict
)>The period is mandatory, lest you execute the prompt as a command
)>(easy on an 8-bit Commodore) and have it do 'READ Y' instead of
)>giving a ?SYNTAX ERROR.
)
)Explain to me how a blurb issued *by* a program will get executed as a
)command typed *into* a program.
I don't know about Commodores, but in Atari 8-bit basic, the way input was
handled was that when RETURN was pressed, the entire logical line that the
cursor was on at the time would be processed. That is, normally you'd type a
line and press RETURN, and it would be interpreted as a command. Or, you
could type a line, backspace and fix something, pressing RETURN while the
cursor is in the middle of the line, and the entire line would be processed.
Nothing unusual about this... except that if you used the arrow keys to move
the cursor to a line of text that already exists, and pressed RETURN, that
line will be immediately processed, even though it had been typed earlier.
This was useful for creating repetitive program statements - LIST the
relative parts of the code, move the cursor into it, and retype the line
numbers - a *very* clumsy block copy. But if you pressed RETURN when the
cursor was on gibberish, then it would try to execute it.
--
Proud member of P.E.T.A. - People for Eating Tasty Animals
hu...@ux1.cso.uiuc.edu WWIVNet 1@2750 WWIVLink 1@12754 Fido 1:233/14
Matt Ackeret
>On the Apple-II you actually had to cursor over the characters, but you could
>insert by manually entering VT52 escape sequences (ESC A, ESC B, etc) an
On the ][+ and later, you can also use ijkm for moving. You also don't have to
hit escape before each movement character (like you do on the ][). You can
then hit a non-movement character to go back into regular mode, and move the
cursor over the lines.
>typing stuff out of sequence. You could also expand a line by listing it,
>cramming extra text between the expansion of the tokenized output, and list
>it again. It'd retokenize so the line would get a bit longer with the new
>expanded spaces.
Of course, before doing any of this, you want to POKE 33,33 if you have any
literal strings in your code that you don't want to have to manually
reconstruct.. (That is, if a string overflows the line onto the next line, and
you move the cursor over all of it, you'll get a bunch of extra spaces in the
middle of your string!)
--
unk...@apple.com Apple II Forever
unk...@ucscb.ucsc.edu These opinions are mine, not Apple's.
Michael Covington
>that the ONE TRUE BASIC PROMPT looks like this:
>
>READY.
>
More fully:
CDC 6400 SCOPE 3.3
02/05/73 10:10:10 [etc.]
...
COMMAND- setup.
SYSTEM: FORTRAN [etc.]
READY.
system,basic.
SYSTEM: BASIC
READY.
(etc.)
I probably have a little of that wrong, and I wrote the user's commands
in lower case to distinguish them, even though they were really upper
case (there is no lower case on that machine!).
But I got acquainted with the One True BASIC Prompt in 1973.
Don Stokes
> insert by manually entering VT52 escape sequences (ESC A, ESC B, etc) an
> typing stuff out of sequence. You could also expand a line by listing it,
> cramming extra text between the expansion of the tokenized output, and list
> it again. It'd retokenize so the line would get a bit longer with the new
> expanded spaces.
Nah, not quite.
The apple ][ had two arrow keys, left and right. The left arrow key
moved the cursor back one character, and erased one character from the
input buffer. The right arrow key added the characater under the cursor
to the end of input buffer and moved the cursor right one character.
This was coupled with the "escape" cursor mode. Pressing Escape put the
cursor in "escape" mode, and you could then use the I,J,K and M keys to
move it around the screen. Pressing Escape again returned you to normal
input mode. Thus, to insert text into a line of BASIC, you'd LIST the
line, press Escape and use the I & J keys to move to the beginning of the
LISTed line, press ESC to return to normal mode, use the right arrow to
copy the line into the input buffer up to the point where you wanted to
start inserting, use escape mode again to get to a clear part of the
screen, type in your text to be inserted, use escape mode to go back to
where you were in the LISTed line before inserting, copy the rest of the
line and press Return. (Phew!)
There were a couple of other commands -- I think one cleared rest of the
line after the cursor -- but it's been a long time since I used a ][ and
bit rot has set in.
When the apple //e came out, the arrow keys were adapted to be usable to
move around when in escape mode (the //e keyboard included up & down arrow
keys that weren't present on the ][ & ][plus keyboards). I think later
versions automatically put you into escape mode on hitting the up-arrow
key too.
The command input always stripped spaces out of the line in the tokenising
process, so getting extra spaces was never a problem. (But of course you
could forget any heretical ideas you might have had about indenting your
code!) The control codes on the ][ were never as sophisticated as the
VT52 either....
--
Don Stokes, CSC Network Manager, Victoria University of Wellington, New Zealand
Ph+64 4 495-5052 Fax+64 4 471-5386 Work:d...@vuw.ac.nz Home:d...@zl2tnm.gen.nz
Frank McConnell
>Anyway, what was so mediocre about the 8-bit Microsoft BASIC? It
>wasn't fancy but it was just the thing for primitive computers
>like the Commodore PET. Calling the old Microsoft BASIC mediocre
>is like calling V7 Unix mediocre... maybe primitive compared to the
>current stuff but very elegant considering the limitations of the
>machines it was meant for.
Well, yes. My original article had a note about how I doubt HP's
BASIC/3000 could have been fit into micros of the day, which were
pretty much limited to a memory address space of 64KB and commonly had
much less (like I remember thinking 16KB was a lot of RAM...of course,
that was on a TRS-80, which had BASIC in ROM).
The HP 3000, on the other hand, allowed ~30K (plus some MPE-reserved
space) of 16-bit words for the segment containing stack and data, with
the code off in (potentially multiple) other segments (and the option
of allocating additional data segments with some funky access
constraints imposed by the fact that the classic 3000 doesn't quite
have the notion of dereferencing a far pointer as we know it today).
This is room for lots more code and about as much data as then-
current micros could handle.
Now, as for how is it mediocre in comparison: the example I had in
mind at the time was the distinction between the Microsoft and HP
flavors of user-defined functions. Microsoft's BASIC restricted these
to single-line algebraic functions, while HP's implementation made
them somewhat more like Pascal functions, with local storage
allocation, support for recursion, and allowing arbitrary BASIC
statements in the body of the function.
Please also keep in mind that I am not comparing MS BASIC of then with
BASICs of today; I'm comparing it with HP BASICs of the same time
frame. I'm not sure how I would rate it against the timeshared BASIC
in the HP 2000 Access machine; that was running on a machine that I'd
really consider similar to then-current micros, had similar
capabilities and limitations (compared to a disk-based MS BASIC like
the TRS-80 disk BASIC), but also supported multiple users.
Then in <1993Jun6.1...@news.columbia.edu>, Charles Lasner
writes:
>Explain to me how a blurb issued *by* a program will get executed as a
>command typed *into* a program.
Commodore machines from early on supported a sort of screen editor.
Basically, when you press ENTER, the line where the cursor is gets
scanned. Prior to that, the characters you typed just got echoed to
display RAM. (Yeah, I know I'm simplifying here -- in particular the
"screen editor" could handle lines that wrapped around, but as I
recall could only handle one wraparound or a maximum of 80 characters
or something like that. It's been a long time, and I never did much
with C= machines, so feel free to jump in.)
This was handy for correcting mistakes: LIST a line, move the cursor
to the right place with the cursor keys, make your changes, and just
press return.
Now, at least some of the C= BASIC interpreters used "READY" for the
prompt. If you put your cursor on this and press return, it gets
parsed as "READ Y". If you used DATA statements in your program, this
would cause the BASIC interpreter to read the next DATA item into Y,
and advance your DATA pointer. Since BASIC was happy it would then
give you another "READY" prompt and there was a good chance you
wouldn't notice your mistake or the side effect, and your program
would either get "wrong" (offset by one) data during its
initialization or would fail with an out-of-data error.
So why is "READY." better? It would get parsed as "READ Y." which
would always be a syntax error and hence would be noticed and not
induce any side effects.
...
Similar line-editing tricks could be with HP terminals, where you
would list the line to be edited out to the terminal, take the "remote
mode" key off (to put the terminal in local mode so editing keys would
not be transmitted to the 3000), edit the lines in the display memory,
then put remote mode back on and use the ENTER key to send the edited
lines one at a time back to the 3000. This was not limited to BASIC,
or to the 3000; you could do these tricks with the HP terminal
attached to just about any system that behaved in a line-oriented
way.
-Frank McConnell, not representing The Wollongong Group
<fr...@twg.com> "I want my MPE" (w/apologies to Dire Straits)
Gabe M Wiener
>pe...@NeoSoft.com (Peter da Silva) writes:
>The apple ][ had two arrow keys, left and right. The left arrow key
>moved the cursor back one character, and erased one character from the
>input buffer. The right arrow key added the characater under the cursor
>to the end of input buffer and moved the cursor right one character.
>
>This was coupled with the "escape" cursor mode.
[stuff deleted]
I should point out that a lot of people got fed up with the clunky way
that the Apple II series handled line editing, and thus in the early
80's there was a plethory of program line editors that one could buy
and add to one's Hello programm (anyone remember Hello programs?) that
would essentially add much of standard GMACS functionality to line
editing.
--
Gabe Wiener -- gm...@cunixa.cc.columbia.edu -- N2GPZ
Sound engineering, recording, and digital mastering for classical music
"I am terrified at the thought that so much hideous and bad music
will be put on records forever." --Sir Arthur Sullivan
Richard William Jones
: : >In article <1993May27.2...@daimi.aau.dk> tu...@daimi.aau.dk writes:
: : >>Yes, the listning was in the great magazin: 'Your Computer'.
: : >>And it worked !!
: : >I've just dug out part 2 of this article. It's in the January 1983 issue of
: : >'Your Computer'.
Ahh! It brings it all back. I remember that article, but I never got
round to typing it in coz you needed a 16K rampack (although the final
program ran in 1K).
I have Artic Chess for the 16K ZX81 at home - in mint condition. I played
it only the other year (it's 10 years old at least). What is the
copyright situation on this game? The company folded up years ago, and
I'm sure they wouldn't _mind_ me distributing it over the net. I
wouldn't do it if it was illegal, though.
I also have lots of other stuff, including Richard Taylor's incredible
program/hack that got you a full bitmapped graphic display. For those
who don't know, the ZX81 was strictly text only (no colour! no, not
even any sound - you had to hack that too!).
Rich.
--
_/_/_/ _/ _/_/ _/ _/ Richard Jones, r...@doc.ic.ac.uk
_/ _/ _/ _/ _/ _/ _/ 319 Fisher Hall, r...@cxa.dl.ac.uk
_/_/_/ _/ _/ _/_/_/_/ 12-30 Evelyn Gardens,
_/ _/ _/ _/ _/ _/ _/ London SW7 3BG.
_/ _/ _/ _/_/ _/ _/ Pop is to music as etch-a-sketch is to art
Guy Dawson
The PET has a full screen editor. An line on which you press return gets
passed to basic to be interpreted. If it starts with a number it is assumed
to be a program statement and is added to the current program. If there
is no line number it is taken to be a statement to be executed here
and down.
Hence anything on the display can be passed to the BASIC interpreter
including the interpreters own output...
>
> cj "full-duplex" l
Guy
--
-- -----------------------------------------------------------------------------
Guy Dawson - Hoskyns Group Plc.
gu...@hoskyns.co.uk Tel Hoskyns UK - 71 251 2128
gu...@austin.ibm.com Tel IBM Austin USA - 512 838 3377
Paul Tomblin
>In article <1993Jun6.1...@news.columbia.edu>, las...@watsun.cc.columbia.edu (Charles Lasner) writes:
>> Explain to me how a blurb issued *by* a program will get executed as a
>> command typed *into* a program.
>The PET has a full screen editor. An line on which you press return gets
>passed to basic to be interpreted. If it starts with a number it is assumed
>to be a program statement and is added to the current program. If there
>is no line number it is taken to be a statement to be executed here
>and down.
Even better than that: there were programs that would modify themselves by
printing the new line to enter on the screen, followed by the command "RUN
100" (or other appropriate line number), position the cursor, stuff a couple
of carriage returns in the buffer, and STOP.
Of course, programmers with access to the Butterfield memory maps and more
time on thier hands hacked into the basic buffer itself to add program lines
without stopping the program. (Or even losing the variables, but that was a
_real_ neat hack)
Paul "Used to hack Commodore basic to get into the TPUG disks" Tomblin
John Park
>ObMicrosoftFlamage: Folks who don't like the fact that Microsoft is
>dominating the PC OS market with mediocre offerings are the new kids
>on the block -- back in the late 1970s, I didn't like the fact that
>Microsoft was dominating the BASIC market with mediocre offerings.
>BASIC/3000 was good (IMNSHO better) stuff. Of course, I'm not sure
>it could be made to fit on microcomputers of the day....
Did you ever run VISICALC/3000? Now there was a program
that would bring a HP3000 to its knees. The spreadsheet was
always loaded into 64K of extra data segments (even if you only had
2 cells). A recalc of the sheet would set the front panel of a
series 68 to a row of solid red lights!
>-Frank McConnell, not representing the opinions of The Wollongong Group
> <fr...@twg.com> "I want my MPE" (w/apologies to Dire Straits)
>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
John Park
Schooler, Park & Associates
Jp...@Jpjazz.win.net
Antonio Vasconcelos
[lots of intersting folklore stuff deleted]
: Commodore machines from early on supported a sort of screen editor.
: Basically, when you press ENTER, the line where the cursor is gets
: scanned. Prior to that, the characters you typed just got echoed to
: display RAM. (Yeah, I know I'm simplifying here -- in particular the
: "screen editor" could handle lines that wrapped around, but as I
: recall could only handle one wraparound or a maximum of 80 characters
: or something like that. It's been a long time, and I never did much
: with C= machines, so feel free to jump in.)
That type of editor was current at the time, I think that was part of
the *standard* MS BASIC, I remember seeing similar editors on the MSX
computers and even in the Amstrad CPC series (NOT MS BASIC, they call
it Locomotive BASIC).
However, Loco Basic had a more sofisticated on-screen editing, you have an
COPY-Cursor witch you move pressing the cursor keys and oher key
(SHIFT ? CTRL ?) and then you have a special COPY key that copy the
char under the copy-cursor to the current line and advance both cursors.
Thats kinda unique I think but the idea is similar to the fuul-screen
editing.
--
regards,
_____
|/asco (Antonio Vasconcelos, Lisbon Stock Exchange: va...@bvl.pt)
Geoff Mccaughan
>Now, at least some of the C= BASIC interpreters used "READY" for the
^^^^^^^^^^^^^
All.
>prompt. If you put your cursor on this and press return, it gets
>parsed as "READ Y". If you used DATA statements in your program, this
>would cause the BASIC interpreter to read the next DATA item into Y,
>and advance your DATA pointer. Since BASIC was happy it would then
>give you another "READY" prompt and there was a good chance you
>wouldn't notice your mistake or the side effect, and your program
>would either get "wrong" (offset by one) data during its
>initialization or would fail with an out-of-data error.
Not really. Your DATA pointer was reset whenever you did a RUN, and the
value in Y would only be an issue if you accessed it before writing
something there, which was a silly thing to do anyway.
The only time this would be a problem would be if you halted your program
with STOP and restarted it with CONT or GOTO, as this wouldn't reset the
DATA pointer.
Most often pressing return on READY just gave an 'out of data error'.
>So why is "READY." better? It would get parsed as "READ Y." which
>would always be a syntax error and hence would be noticed and not
>induce any side effects.
--
Geoff, Sysop Equinox (equinox.gen.nz) +64 (3) 3854406 [6 Lines]
"If you have to run heating in winter, you don't own enough computers."
Vote SPQR Ski Nix Olympica Freedom for Axolotls
Danny R. Faught
>Not really. Your DATA pointer was reset whenever you did a RUN, and the
>value in Y would only be an issue if you accessed it before writing
>something there, which was a silly thing to do anyway.
Almost. The variables were also reset when you did a 'run', so Y
would always be reset to 0.
>The only time this would be a problem would be if you halted your program
>with STOP and restarted it with CONT or GOTO, as this wouldn't reset the
>DATA pointer.
True.
--
Danny Faught -- Convex rookie -- MPP OS Test Development
"Everything is deeply intertwingled." (Ted Nelson, _Computer Lib_)
Guy Dawson
This type of COPY-Cursor was also on the BBC micro. I don't know which came
first.
I experienced my first relgious war in arguments over the PET style full
screen and the BBC style copy-cursor. Happy times :-)
> --
>
> regards,
> _____
> |/asco (Antonio Vasconcelos, Lisbon Stock Exchange: va...@bvl.pt)
>
William T. Warner
Sure - some versions of MS-DOS BASIC (GW-Basic, I think) read the commands
directly off the screen; you can move around with the arrows,
press enter, and the text on that line is executed.
Sort of like how GNU Emacs does with command windows.
Bill
--
Bill Warner | Worcester Polytechnic Institute, CS graduate program.
w...@cs.wpi.edu | ** Using OS/2 2.x and 386BSD **
Lennart Benschop
: program/hack that got you a full bitmapped graphic display. For those
: who don't know, the ZX81 was strictly text only (no colour! no, not
: even any sound - you had to hack that too!).
How the ZX81 does graphics.
In this article I'll try to describe how the ZX81/Timex 1000
generates its video signal and how high-resolution hacks work.
This info is a recollection from memory, read long time ago in
magazines, heard from people who claimed to know etc.
Therefore don't expect this info to be complete and accurate.
It would be a good idea to lay my hands on a copy of the Timex1000
ROM Diasssembly or disassemble the interrupt handlers myself.
The ZX81 contains four IC's. These are:
- The Z80A CPU of course.
- The SInclair Logics IC, which is a combination of an 8 kilobyte ROM
and a gate-array. It contains a bunch of counters and shift
registers to generate the video signal, a 5-bit input port for the
keyboard and a 1-bit I/O port for tape.
- Two 1k x 4 bits static RAM IC's.
The 16K RAM pack contains 8 16k x 1 bit dynamic RAM IC's plus a few
TTL chips to convert the bus signals to RAS/CAS etc. The static RAM
chips were completely disabled if the RAM pack was there. Probably
you could take them out and sell them.
Call this a computer, man. The keyboard was just an 8x5 matrix with a
membrane contact at each crossing. (the keyboard appeared to have 4
rows of 10 keys but it was wired as 8 rows and 5 columns.) The 8 rows
were connected to the 8 most significant lines of the address bus.
The 5 columns were read out through port 0FEh on the Sinclair Logics
chip. The normal IN instruction had the side-effect that the
contents of the A-register were placed on the most significant
address lines and the IN (C) instructions placed the contents of B on
the most significant lines of the address bus. So you could place the
desired pattern on the rows of the matrix (seven 1s and 1 zero) and
read out the columns. So you could scan the whole matrix in 8 IN
instructions. Apparently the membrane keyboard was resistive enough
that you couldn't short two address lines and screw up your computer.
Back to video. The ROM is at addresses 0-1fffh. The character
patterns were from 1e00h to 1f00h. RAM was from 4000h to
43ffh (1k) or 7fffh (16k). Part of the RAM contained the
character codes on each line (non-ascii, even no Petscii or ebcdic,
the ZX81 had its Own Patented Copyrighted Character Code). Each line
was terminated by the byte 076h (This is equal to the opcode for the
HALT instruction). The last line was terminated with two bytes 76h.
There was a maximum of 24 lines (the 1k version could only hold that
many if there was no program in memory.)
Now the interesting part: The CPU and the Sinclair Logics chip needed
to cooperate very closely to get a picture on the screen. Each video
frame consisted of 312 lines (half of 625), 192 of which contained
the picture and the rest was empty. Only during the empty lines real
work could be done. Even during the empty lines there was an
interrupt at every line and the Z80 had to count out the vertical
retrace interval and sync pulse. (is that true? or could the Logics
Chip count down the scan lines for vertical retrace and sync by
itself?) Three quarters of all the processing time was consumed by
video. The ZX81 had a fast mode in which all video processing was
disabled, No picture and even no frame. Remember the tape loads? No
sync, looked like scrambled cable tv signal.
So what did the CPU do when generating video signals? Before the
start of a picture line, the IX register pointed to the right line of
character codes. Then a HALT instruction was executed. At the right
time, the CPU got an NMI and executed the NMI handler, which was
basically a JMP(IX). So the CPU jumped into the video RAM! Then the
Sinclair Logics chip filtered out the data to the CPU and the CPU saw
only byte zero, the opcode for NOP. So the CPU executed NOP
instructions. Meanwhile it still addressed the video RAM and the
Sinclair Logics chip saw the right character codes. During each
execution cycle, the CPU had a refresh cycle in which it put the
value of the I register on the address bus. It was that value on the
address bus that the Sinclair Logics chip used as the most
significant part of the address into the character ROM (worked for ROM only).
After the character code was read from RAM the sinclair chip read the
pattern code from ROM at the address
(I*256+(character_code and 63)*8+scan_line) and 16383
You could get a gibberish character set by just altering the I register,
weird! The character ROM contained 64 character codes. Bit 7 of the
character code indicated inversed video, bit 6 had to be 0.
The line of character codes ended with byte 76h. Apparently this got
passed unchanged to the CPU again (a HALT instruction). Immediately
after this it got an interrupt (regular interrupt). Its handler
updated the IX register if the character line had been passed over 8
times. (each character had 8 scan lines). After the last picture
line, the CPU didn't receive NMI's during the vertical retrace
interval (with the associated data filtering) and the CPU had some
time to get some real work done. It did get regular interrupts
though. (how often, each line or just prior to the start of a new
frame? I think the first but someone is sure?)
THe Z80 had three different interrupt modes. Normally IM1 was in
effect which meant that the interrupt handler was at address 038h in
ROM. The only way to pull the interrupt handler out of ROM was
setting the Z80 to IM2. Then the interrupt address was a vector
stored in RAM at an address determined by the I register. If you
could change the interrupt handler you could have a differnt line of
character codes at every scan line. Further you could change the
contents of I at every scan line (I was used both as interrupt vector
address and as character ROM address in this application).
This gave you a very high control over the graphics output though it
was still not possible to get true bimapped graphics. It required
Real Programming(tm) but you could approximate bitmapped graphics
nicely with it.
Any comments/corrections/flames/clarifications/completions on this
explanation of ZX81 hardware?
--
Lennart Benschop --- len...@stack.urc.tue.nl
"Real programmers do it in hacks"
52 65 61 6C 20 70 72 6F 67 72 61 6D 6D 65 72 73 20 64 6F 20 69 74 20
69 6E 20 68 61 63 6B 73 2E Forth/C/6809/Linux/ZX-Spectrum/Z80/80x86
Charles Lasner
>las...@watsun.cc.columbia.edu (Charles Lasner) writes:
>>Explain to me how a blurb issued *by* a program will get executed as a
>>command typed *into* a program.
>
>On Commode machines you press cursor up and return. That's screen
>editing ya know. (disclaimer: I never owned one)
Oh, I forgot, these are *tiny* little machines. There wasn't a spare bit to
tell the difference between outputted blurbs and inputted keystroke echoes.
I didn't realize these machines were smaller than a 4K PDP-8 (where this
problem never happened).
cjl
Andy Holyer
: Sure - some versions of MS-DOS BASIC (GW-Basic, I think) read the commands
: directly off the screen; you can move around with the arrows,
: press enter, and the text on that line is executed.
: Sort of like how GNU Emacs does with command windows.
But using a tad less system resources. :-). Honestly people, isn't
there something just a little strange about us if we get postings
saying "Oh yes, I remember BASIC, it's a bit like GNU Emacs".
-Andy "Eventually Malloc's All Core Storage" Holyer
--
&ndy Holyer, School of Cognitive and |'Is it angst or too much lager?'
Computing Studies, University of Sussex, | 'POSSIBLY!'
JANET: an...@cogs.sussex.ac.uk | - Andy White
Paul Tomblin
>In article <IISAKKIL.9...@vipunen.hut.fi> iisa...@vipunen.hut.fi (Mika Iisakkila) writes:
>>las...@watsun.cc.columbia.edu (Charles Lasner) writes:
>>>Explain to me how a blurb issued *by* a program will get executed as a
>>>command typed *into* a program.
>>
>>On Commode machines you press cursor up and return. That's screen
>>editing ya know. (disclaimer: I never owned one)
>Oh, I forgot, these are *tiny* little machines. There wasn't a spare bit to
>tell the difference between outputted blurbs and inputted keystroke echoes.
That's not a bug, it's a FEATURE! There were times when you _wanted_ to be
able to change something on the screen and enter it - editing BASIC programs
was just one case. Writing self modifying code was another. Doing
repetative stuff in immediate mode was another.
M Gordon
>Richard William Jones (r...@motmot.doc.ic.ac.uk) wrote:
>: program/hack that got you a full bitmapped graphic display. For those
>: who don't know, the ZX81 was strictly text only (no colour! no, not
>: even any sound - you had to hack that too!).
>How the ZX81 does graphics.
[Description of the ZX81's hideous display setup deleted]
The Spectrum, Sinclair's next machine, wasn't anywhere near this weird,
but it didn't exactly have what most people would consider a reasonable
way of handling the screen (at least not now, chip speeds at the time
may have made this more attractive).
The Spectrum didn't have separate text and graphics screens, everything
went to a 256x192 bitmapped display. The weird part was the mapping
of RAM to screen lines. The first 32 bytes of screen memory held line 0,
the next 32 held line 8, the next 32 line 16 etc. This arrangement
continued upto line 56. The 32 bytes after that held line 1, the next
32 line 9 and so on upto 57, where it went back to line 2. When all
of the lines 0-63 were done it repeated this with 64-127, then 128-191.
The reason for this arrangement was to speed up text display. The
characters were designed on a 8x8 grid and could only be printed
at positions such that x%8==0 and y%8==0, giving a 32x24 text screen.
Characters were printed with something like
ld hl,address of char data in ROM
ld de,address of screen posn for first line of char
ld b,8
loop:
ld a,(hl)
ld (de),a
inc hl
inc d
djnz loop
Notice the inc d, NOT inc de. The screen arrangement meant that consecutive
lines of the character were 256 bytes apart, so you could get to the next
position by incrementing the high byte of a register pair. With the more
obvious layout you'd have had to muck about adding 32 each time.
The calculation of a memory address for a given y coordinate wasn't as bad
as it sounds either - a fairly simple sequence of masking and bit shifts,
which I can't remember or be bothered to work out, would do it.
--
Michael Gordon - m...@castle.ed.ac.uk OR ee.ed.ac.uk
Computing Officer, EE Dept, Edinburgh University
It's not an optical illusion, it just looks like one
Tor Iver Wilhelmsen
Neither did I, but I used one occasionally, and owned an ORIC-1 (anyone
remember those?) which did it that way too. Yes, you could edit directly
on the screen, but the length of program lines was restricted to two
screen-lines, program line number including. You had the option of
shortening the commands (Bot C64 and ORIC used '?' as a shorthand for
print for instance), but in the resulting program the words were expanded,
so that you couldn't edit the line if it exceeded the allowed 80 chars.
The ORIC-1 was awful and I loved it. Pity I sold it... Anyone know whether
Tangerine Systems ever produced one of their "Stratos" computers for the
French market?
- Tor Iver
--
"I'm a Derek, and Dereks don't run!" - Derek in 'Bad Taste'
tor...@pvv.unit.no
Standard disclaimer should apply to this, I guess...
"Reality is a poor escapism for people who cannot handle roleplaying" - Me
Markus Wandel
>
>The Spectrum didn't have separate text and graphics screens, everything
>went to a 256x192 bitmapped display. The weird part was the mapping
>of RAM to screen lines. The first 32 bytes of screen memory held line 0,
>the next 32 held line 8, the next 32 line 16 etc. This arrangement
>continued upto line 56. The 32 bytes after that held line 1, the next
>32 line 9 and so on upto 57, where it went back to line 2. When all
>of the lines 0-63 were done it repeated this with 64-127, then 128-191.
The Commodore 64's bitmap display mode is weirder than that. The screen
is divided into 8x8 pixel character cells and the the first 8 bytes are
the first character cell, the next 8 are the second, and so on. So
the 8-pixel groups in the top left corner are addressed something like
this:
----0--- ----8--- ---16--- ---24---
----1--- ----9---
----2---
----3---
----4---
----5---
----6---
----7---
--320---
--321---
The machine has a separate text display mode so it is not necessary to be
able to plot characters to the bitmap screen all that efficiently. So
why did they do it this way? Probably because there is a separate
"colour map" of 1K x 4 bits, allowing you to select the colour of each
character position of the screen, and this remains active in the bitmap
mode. So in "monochrome bitmap" mode you have 320x200 pixels with the
colour of each 8x8 cell of pixels separately settable, and in "multicolour
bitmap" mode you have 160x200 pixels with colours 1 and 2 common all
characters and colour 3 individually settable for each 4x8 group. It's
amazing how useful this is; a lot of 'paint' programs allowed you to treat
the whole screen as a 160x200, 16-colour display and would juggle the
character colour map and global colour registers to make it work. Only
sometimes if too many colours got too close together some pixels would
be wrong. It was easy to draw your pictures in a way that avoided this.
Anyway the first time I saw this I was horrified. It did not look
possible to write efficient code to manipulate the bitmap display. And
yet every time you needed to do it there was always a way to program it
that was just as efficient as it would have been if the pixels were truly
sequentially addressed. For example, to move down you had to increment
the address by one 7 times of 8, then add 320 the eighth time. Much
more efficient on a 6502 than adding 40 every time.
On the C64 you also see some simple games where all the action is
conveniently in the left 3/4 of the screen and a column on the right is
taken up by score displays, etc. Coincidence? Hardly. Crossing into
that right hand area was a pain because you had to start manipulating
the 9th bit of the X position of the sprites. A real pain on an 8-bit
machine.
I hope I'm not boring too many folks.
Markus Wandel Ottawa Ont. Canada (613) 592-1225
mar...@pinetree.org <-- NOT 'mwa...@bnr.ca', that does not work.
John West
>len...@stack.urc.tue.nl (Lennart Benschop) writes:
>>Richard William Jones (r...@motmot.doc.ic.ac.uk) wrote:
>>: program/hack that got you a full bitmapped graphic display. For those
>>: who don't know, the ZX81 was strictly text only (no colour! no, not
>>: even any sound - you had to hack that too!).
>[Description of the ZX81's hideous display setup deleted]
>The Spectrum, Sinclair's next machine, wasn't anywhere near this weird,
>but it didn't exactly have what most people would consider a reasonable
>way of handling the screen (at least not now, chip speeds at the time
>may have made this more attractive).
The Spectrum also had some pretty evil hardware. In a scheme similar to the
Amiga's chip/fast RAM, there was 32K of fast memory that only the processor
could access (the only place you'll ever see 32K*1 DRAM), and 16K shared
between the processor and video. Any normal design would place a heap of
buffers between the two, so video addresses and data placed on that half of
the bus wouldn't intefere with processor address and data. No no no. Far too
expensive. They used resistors. When the video wasn't doing anything, it
went tri-state, and the processor signals could make it through the
resistors to that half of the bus. When it was accessing RAM, you'd get
different voltages on either end of the resistor - a small current running
through it, but no real problem.
John West
Lennart Benschop
: The Spectrum also had some pretty evil hardware. In a scheme similar to the
: Amiga's chip/fast RAM, there was 32K of fast memory that only the processor
: could access (the only place you'll ever see 32K*1 DRAM),
of the RAM chips was used, the half that was supposed to be OK.
There was a wire jumper on the circuit board that selected which half of the
chips was used. When partially defective chips were getting scarce, good
ones were used. There was a small modification (just a few gates) that gave
you 2 switchable banks of 32k, so you got an 80k Spectrum.
: and 16k shared
: between the processor and video. Any normal design would place a heap of
: buffers between the two, so video addresses and data placed on that half of
: the bus wouldn't intefere with processor address and data. No no no. Far too
: expensive. They used resistors. When the video wasn't doing anything, it
: went tri-state, and the processor signals could make it through the
: resistors to that half of the bus. When it was accessing RAM, you'd get
: different voltages on either end of the resistor - a small current running
: through it, but no real problem.
You forgot to tell, that when the video chip (ULA) was accessing RAM and the
CPU tried to address the video RAM at the same time, the ULA shut off the
Z80's clock (what's a wait state?) for a few microseconds. Programs that
needed accurate software timing (sound generation, tape load and save) had
to reside either in ROM or in the higher 32k of RAM. 16k spectrums could not
have fast tape loaders for that very reason.
Keyboard setup was exactly the same as the ZX81. Enhanced Spectrum keyboards
had a very complicated membrane structure in which two contacts were closed
at the press of a single key. (the dot key activated Symbol Shift and M
simultaneously.)
The only interrupt was a 50Hz timer interrupt. As with the ZX81 you had to
use IM2 to have your own handler. You couldnt set the I register to
locations in the video RAM because the ULA (some versions) got disturbed
and the result was a disturbed picture. With Interrupt mode 2, the Z80
expected a vector number on its bus, which it didn't get of course, so you
got 0ffh by default. If you were more scrupulous, you had to select a
symmetric address for your interrupt handler (like 8181h) and cover an
entire 256-byte page plus the next byte with that byte value.
The naked Spectrum had only one input port and one output port, both at
address 0feh. That was enough for keyboard, tape, sound and border color.
Some interesting evil hardware was to be found in the ZX Printer and the
Interface-1 and associated Microdrives too. Suffice it to say that
Interface-1 had an internal ROM and that it was switched at the address of
the normal ROM. The switch was triggered by the opcode of the 'RST 8'
instruction, which normally invoked the error handler. So when a microdrive
command was started, the Basic ROM thought it was an error, invoked the
error handler and the program proceeded in the alternate ROM instead.
I got an Issue-2 Spectrum with a transistor patched over the CPU. Color
generation is almost dead. Last time I tried, it still worked.
Mitraglia
|> The Spectrum also had some pretty evil hardware. In a scheme similar to the
|> Amiga's chip/fast RAM, there was 32K of fast memory that only the processor
|> could access (the only place you'll ever see 32K*1 DRAM), and 16K shared
|> between the processor and video.
..Of which only the first 6912 bytes were really accessed by the Ferranti ULA.
So all the 16K bank got the slowdown.
And the image was split in three parts of 64 lines each, stored in a curious
"interleaved" way (8 groups of 8 lines..)
Can you tell me a reason for that nightmare-like display file scheme?
--
_ _ _ _ _ _ e-mail addr (until 18-8-93):
' ) ) ) ' ) ) ) s...@bach.cefriel.it
/ / / __. __ _. __ / / / . . _ _ o ____ o (-: Marco Mussini
/ ' (_(_/|_/ (_(__(_) / ' (_(_/_/_)_/_)_<_/ / <_<_ Milano, ITALY
Mika Heiskanen
In article <1993Jun9.1...@bnr.ca> mwa...@bnr.ca (Markus Wandel) writes:
>In article <37...@castle.ed.ac.uk> m...@castle.ed.ac.uk (M Gordon) writes:
[..]
>mode. So in "monochrome bitmap" mode you have 320x200 pixels with the
>colour of each 8x8 cell of pixels separately settable, and in "multicolour
>bitmap" mode you have 160x200 pixels with colours 1 and 2 common all
>characters and colour 3 individually settable for each 4x8 group. It's
>amazing how useful this is; a lot of 'paint' programs allowed you to treat
>the whole screen as a 160x200, 16-colour display and would juggle the
>character colour map and global colour registers to make it work. Only
>sometimes if too many colours got too close together some pixels would
>be wrong. It was easy to draw your pictures in a way that avoided this.
[..]
Any every 8th line was used by VIC to update the colormap etc. By
scrolling it along with the display (scrolling it down the moment the
pixel line changes) you could change colormaps every screen line. This
allowed much more colors. Then you could also change the bitmap every
screen update, and by choosing the color pairs in the 2 screens carefully
you got quite smooth colours. I used it to plot Mandelbrot pictures.
Later I saw one picture drawn this way too, looked quite good too.
--
---> Mika Heiskanen, mhei...@delta.hut.fi
Richard Carlsson
>In article <37...@castle.ed.ac.uk> m...@castle.ed.ac.uk (M Gordon) writes:
>>
>>The Spectrum didn't have separate text and graphics screens, everything
>>went to a 256x192 bitmapped display. The weird part was the mapping
>>of RAM to screen lines. The first 32 bytes of screen memory held line 0,
>>the next 32 held line 8, the next 32 line 16 etc. This arrangement
>>continued upto line 56. The 32 bytes after that held line 1, the next
>>32 line 9 and so on upto 57, where it went back to line 2. When all
>>of the lines 0-63 were done it repeated this with 64-127, then 128-191.
>
>The Commodore 64's bitmap display mode is weirder than that. The screen
>is divided into 8x8 pixel character cells and the the first 8 bytes are
>the first character cell, the next 8 are the second, and so on.
>Anyway the first time I saw this I was horrified. It did not look
>possible to write efficient code to manipulate the bitmap display. And
>yet every time you needed to do it there was always a way to program it
>that was just as efficient as it would have been if the pixels were truly
>sequentially addressed. For example, to move down you had to increment
>the address by one 7 times of 8, then add 320 the eighth time. Much
>more efficient on a 6502 than adding 40 every time.
Exactly the reason why the Spectrum display mapping was "logical".
With a Z80, you normally address the screen with a register pair like HL.
Doing an "Inc L" would of course bring you to the next column, but when
you get to the last column, you don't wrap to the next pixel line as
with a "sequential" mapping, but to the next character row.
Doing an "Inc H" on the other hand will have the effect of incrementing HL
by 256 and so stepping down one pixel line. This makes output of characters
(at least 8x8 ones) very quick and simple.
Amazingly, in a generic "sprite"-drawing routine that positions the graphic
object at any pixel position, the number of tests involved are still simpler
and quicker than if the mapping had been linear. You only have to check for
block and character row limits, and only need to do the test every 7th line.
The tests are simple operations on 8 bits, or merely flag checking after
8-bit increments/decrements.
You have to plan your routine carefully, but it will be very quick!
--
<dead.sig>
Calum F Benson CS90
>
>I also have lots of other stuff, including Richard Taylor's incredible
>program/hack that got you a full bitmapped graphic display. For those
>who don't know, the ZX81 was strictly text only (no colour! no, not
>even any sound - you had to hack that too!).
Ah yes - I've still got that CRL program too. But it was so slooow ... or at
least, it was compared to the amazing hi-res games (one of which was called
'Rocket Man', I believe) which came out for the ZX81 - in fact, wasn't it
Artic who released them too?
+---------------------------------------------+---------------------------+
| | CALUM BENSON |
| "Studying for the wrong chapter is like | 4TH YEAR COMPUTER SCIENCE |
| cutting your fingernails too short" | University of Strathclyde |
| | Glasgow, Scotland |
+---------------------------------------------+---------------------------+
| cbe...@uk.ac.strath.cs AND cad...@uk.ac.strath.ccsun |
+-------------------------------------------------------------------------+
Calum F Benson CS90
>Bernd Meyer (ro...@umibox.hanse.de) wrote:
>: mar...@llanelli.demon.co.uk (Martin Thomas) writes:
>
>PC. It is called XTender, and can be ftp'ed from src.doc.ic.ac.uk in the directory
>/computing/systems/ibmpc/wsmr-simtel20.army.mil/emulators/xtndr093.zip
You can get one for the Atari ST as well ... don't know how good it is,
though; I'm an Amiga bod myself. (Although my 'recursive emulation' theory
would allow me to try it out .. see the Amiga 'chameleon' thread :-) ).
Martin Thomas
>In article <1993Jun8.0...@bvl.pt>, va...@bvl.pt (Antonio Vasconcelos)
> writes:
[stuff deleted]
>> However, Loco Basic had a more sofisticated on-screen editing, you have an
>> COPY-Cursor witch you move pressing the cursor keys and oher key
>> (SHIFT ? CTRL ?) and then you have a special COPY key that copy the
>> char under the copy-cursor to the current line and advance both cursors.
>>
>> Thats kinda unique I think but the idea is similar to the fuul-screen
>> editing.
>
>This type of COPY-Cursor was also on the BBC micro. I don't know which came
>first.
The BBC micro came first, about mid 82, I think the Amstrad machine first
appeared around about 84/85. I seem to remember the Beeb's screen editor
used to get unfavourably compared with other machines of that period, 64's etc.
I kinda liked it myself.
--
Martin Thomas +44-0554-770546 | "Man masters nature not by force but by
mar...@llanelli.demon.co.uk | understanding. That is why science has
7037...@CompuServe.com | succeeded where magic has failed: it has
CompuServe: 70374,332 | looked for no spell to cast on nature."
| Jacob Bronowski - Science & Human Values
Arnt Gulbrandsen
>In article <1v6l3a$c...@uniwa.uwa.edu.au>, jo...@gu.uwa.edu.au (John West) writes:
>|> The Spectrum also had some pretty evil hardware.
>And the image was split in three parts of 64 lines each, stored in a curious
>"interleaved" way (8 groups of 8 lines..)
>
>Can you tell me a reason for that nightmare-like display file scheme?
Certainly. There were some (non-obvious) very fast instruction sequences
to do common operations on the display.
Re another part of the thread, several games set the interrupt vector to
point to an unused page of the ROM, which contained 0xFFFF. Chequered
Flag springs to mind. The CPU would jump to 0xFFFF, find the first byte
of a relative jump instruction, wrap around and read the offset from
0x0000 (the first byte of the ROM), jump to 0xFFF4 where it would find,
typically, an absolute jump into the interrupt handler.
It did save 256 bytes...
But the most impressive space-scrounging technique I've seen was using the
RAM refresh register to hold a value. You see, the refresh circuitry was
only 7-bit but the register was 8-bit like the others, so the msb could be
used to store a single bit. Several games, for instance Tomahawk by
Digital Integration, used it.
--
Arnt Gulbrandsen
agu...@nvg.unit.no
David E A Wilson
>code!) The control codes on the ][ were never as sophisticated as the
>VT52 either....
Here is my terminfo entry for my dumb terminal program which uses the
Pascal 1.1 entry point to the video firmware. The alternate character
set does not quite work for drawing boxes (Apple's boxes are not centered).
apple2e|apple //e 80 column card,
am, bw, xon,
cols#80, lines#24,
acsc=+U\,H.J0N-KiC`[aVh]oLqS, bel=^G, civis=^F,
clear=\f, cnorm=^E, cr=\r, cub1=\b, cud1=\n, cuf1=^\,
cup=^^%p2%'\s'%+%c%p1%'\s'%+%c, cuu1=^_, ed=^K, el=^],
home=^Y, ind=^W, kbs=\b, kcub1=\b, kcud1=\n, kcuf1=^U,
kcuu1=^K, kdch1=^_, rev=^O, ri=^V, rmacs=^X^N,
rmso=^N, sgr0=^X^N, smacs=^O\E, smso=^O,
And my WP-3 implements VT52 except that the direct cursor position codes are
NOT offset by 32. <ESC> Y <NUL> <NUL> to home the cursor. Crazy.
--
David Wilson +61 42 213802 voice, +61 42 213262 fax
Dept Comp Sci, Uni of Wollongong da...@cs.uow.edu.au
Hierophant
>The Spectrum also had some pretty evil hardware. In a scheme similar to the
>Amiga's chip/fast RAM, there was 32K of fast memory that only the processor
>could access (the only place you'll ever see 32K*1 DRAM), and 16K shared
Gotta point it out: Apple /// memory expansion boards used 32Kx1 DRAM
chips, which were actually two 16Kx1 DRAMs mounted on an 18-pin ceramic
base. Truly hideous, and still required the triple voltages (+/- 5, +12).
I've still got some at home, even though I never had an Apple /// in which
to put them...
--
%% Duem ex Machina Contrarius Machinator est
%% Internet oz...@sanger.chem.nd.edu snail ja...@box-875.46556.usps.gov
%% admin ro...@sanger.chem.nd.edu decnet BIOCOR::SYSTEM
%% "One Nation under Surveillance, with Wiretaps and Mail Covers for All."
PDP11 Hacker .....
The 32K DRAMs used in the spectrum, and in certain models of Tandy CoCo
(according to the techref) were 64K devices with 1 half defective. There were
links on the board to select which half was to be used - all the DRAMs on a
particular board had to have the same good half.
The 2-16K-chips-on-a-hybrid rams were also used (according to the IBM techref)
in certain IBM PC memory expansion cards, and were certainly used in one
version of the 3 rivers PERQ 2M memory card. The other version of said card
used 1/2 as many 256K chips.
-tony
PDP11 Hacker .....
The Spectrum (and some models of Tandy CoCo, according to the techref) used 32K
DRAMs which were actually 64K ones with 1 half defective. There were links on
the board to select which half would be used - obviously , all the drams on the
board had to have the same good half.
The 2-16K-chips-on-a-hybrid were also used in some early IBM PC expansions
(again, they're mentioned in the techref, but I've never seen one), and also in
one version of the PERQ 2M memory board. The other version of this board used
1/2 as many 256K drams of conventional design.
-tony
Richard William Jones
: In article <1uvu1q...@frigate.doc.ic.ac.uk> r...@motmot.doc.ic.ac.uk (Richard William Jones) writes:
: >
: >I also have lots of other stuff, including Richard Taylor's incredible
: >program/hack that got you a full bitmapped graphic display. For those
: >who don't know, the ZX81 was strictly text only (no colour! no, not
: >even any sound - you had to hack that too!).
: Ah yes - I've still got that CRL program too. But it was so slooow ... or at
: least, it was compared to the amazing hi-res games (one of which was called
: 'Rocket Man', I believe) which came out for the ZX81 - in fact, wasn't it
: Artic who released them too?
Software farm released several good hi-res games for the zx81. The best
was the digdug clone called ... (the name escapes me) ...
--
_/_/_/ _/ _/_/ _/ _/ Richard Jones, r...@doc.ic.ac.uk
_/ _/ _/ _/ _/ _/ _/ 319 Fisher Hall, r...@cxa.dl.ac.uk
_/_/_/ _/ _/ _/_/_/_/ 12-30 Evelyn Gardens,
_/ _/ _/ _/ _/ _/ _/ London SW7 3BG.
_/ _/ _/ _/_/ _/ _/ Pop is to music as etch-a-sketch is to art
Stephen Usher
The Atari ZX81 emulator is VERY good and on a TT emulates a 10MHz ZX81 speedwise.
Grin
Steve
--
---------------------------------------------------------------------------
Computer Systems Administrator, Dept. of Earth Sciences, Oxford University.
E-Mail: st...@uk.ac.ox.earth (JANET) st...@earth.ox.ac.uk (Internet).
Tel:- Oxford (0865) 282110 (UK) or +44 865 282110 (International).
Paul Ducklin
>Neither did I, but I used one occasionally, and owned an ORIC-1 (anyone
>remember those?)
The first person I've ever heard of who's ever heard of ORICs and who
isn't me!
>The ORIC-1 was awful and I loved it. Pity I sold it...
Wow. I had an ORIC ATMOS. Paid \Pounds 90 for it. It was total shite,
if the truth be told -- but *great*. Redefinable character sets; sound
[after a fashion]; plenty of memory [48K]; very small and light. It
had a cassette interface which could do 300bps or 2400bps, but the 2400
bps was not totally reliable. However, it was reliable enough to risk
saving, say, 2 or 3 times at 2400bps -- and still faster than 300.
The weirdest thing about it was that the video subsystem was Prestel!
It wasn't just that it supported Prestel emulation [as did the BBC].
Prestel was *it*. None of the standard 2-bytes-per-text-char, like
most text schemes [including the PC] -- all colour control was done
via the Prestel sequences. There were BASIC commands, though [PAPER
and INK...], which emitted the requisite sequences for you.
It also had the BASIC commands PING, ZAP, SHOOT and EXPLODE. Far, far
out. I only ever in my life saw 2 cassettes of ORIC programs. One was
the demo which came with the machine [and which had some fair animation
in, actually -- a bird flying across the screen] and the other was the
most steamingly turdacious piece of code I've ever experienced in my
life -- a sort of assembler/debugger/editor called ORICADE that should
have been persecuted under the Trades Descriptions Act.
Weird item from the manual in the version I had -- "This ROM release
fixes a bug in Ver 1.0 which caused the CIRCLE command to produce
ovals".
When I heard that Tangerine had gone down the toilet shortly after I
bought the ORIC, I was somewhat less than surprised :-)
Paul
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\ Paul Ducklin du...@nuustak.csir.co.za /
/ CSIR Computer Virus Lab + Box 395 + Pretoria + 0001 S Africa \
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
I108...@dbstu1.rz.tu-bs.de
len...@stack.urc.tue.nl (Lennart Benschop) writes:
>You forgot to tell, that when the video chip (ULA) was accessing RAM and the
>CPU tried to address the video RAM at the same time, the ULA shut off the
>Z80's clock (what's a wait state?) for a few microseconds. Programs that
>needed accurate software timing (sound generation, tape load and save) had
>to reside either in ROM or in the higher 32k of RAM. 16k spectrums could not
>have fast tape loaders for that very reason.
ULA didn't have any pins left for /WAIT. If you built a discrete ULA using
TTL chips (I did) it works just fine with waitstates.
The discrete ULA schematics originated in the former GDR. It was called
"colour graphics card" for some do-it-yourself computer.
It's been fun to construct a 10 MHz Spectrum with this thing...
Hanno Foest
Mitraglia
>isn't me!
I never bought an ORIC, but I knew it. I should have a tech review on some
1982 MC Microcomputer issue..
Anybody wants online a GIF of an Oric Atmos ?
--Let me know.
PS: And how much people will remember the 6809-based Dragon 32 ?
PS2: Anybody on the Net ever owned an Apricot ??
Peter Gutmann
>When I heard that Tangerine had gone down the toilet shortly after I
>bought the ORIC, I was somewhat less than surprised :-)
"Alas, poor ORIC, I knew him well...."
Peter.
Erkki Ruohtula
>Thus spake tor...@flipper.pvv.unit.no (Tor Iver Wilhelmsen):
>>Neither did I, but I used one occasionally, and owned an ORIC-1 (anyone
>>remember those?)
>
>The first person I've ever heard of who's ever heard of ORICs and who
>isn't me!
I think they were relatively common here in Finland at one time. I had one and
knew of 4 other owners in my vicinity. When the ORIC-1 was introduced here in
1983, it looked like a good value for the money: A 48k RAM machine with a full
BASIC for (I think it was) 2700 marks (about $540). At the time the other
computers in the same price category came with 16k or less.
So I, an enthousiastic newbie, went and paid this huge amount of hard-earned
money for it. Unfortunately I did not know about the buggy ROM and the weird
approach to graphics...
>>The ORIC-1 was awful and I loved it. Pity I sold it...
>
>Wow. I had an ORIC ATMOS. Paid \Pounds 90 for it. It was total shite,
>if the truth be told -- but *great*. Redefinable character sets; sound
>[after a fashion]; plenty of memory [48K]; very small and light. It
The ATMOS had a real keyboard. My ORIC-1 had some kind of calculator keys,
although the keyboard was almost full-size. Another difference between the two
is the ROM, the ATMOS version (v1.1) had most of the v1.0 bugs fixed.
After a while I found that my family did not quite appreciate my monopolizing
of the TV set with the computer, so I bought a cheap portable B&W set (made in
Poland). You can imagine the staggering ergonomy of the resulting
workstation...to get a steady picture, one had to now and then adjust the
vertical synchronization of the TV set as the computer (or the TV set, or was
it both) warmed up. And this is what I spent untold nights hacking ten years
ago, computers can be really addictive in all their forms...
>had a cassette interface which could do 300bps or 2400bps, but the 2400
>bps was not totally reliable. However, it was reliable enough to risk
>saving, say, 2 or 3 times at 2400bps -- and still faster than 300.
I found the 2400bps speed quite reliable, if one used the same, good-quality
recorder for saving and loading. The playback head alignment was crucial
when exchanging tapes. I finally found that to read tapes saved on other
machines, one must adjust the head alignment while playing the screeching
through the speaker until it sounds as crisp as possible.
One of the most irritating bugs in the v1.0 ROM prevented the BASIC LOAD
command from correctly loading other than BASIC files into the memory. There
were ways around this in machine code.
>The weirdest thing about it was that the video subsystem was Prestel!
>It wasn't just that it supported Prestel emulation [as did the BBC].
>Prestel was *it*. None of the standard 2-bytes-per-text-char, like
>most text schemes [including the PC] -- all colour control was done
>via the Prestel sequences. There were BASIC commands, though [PAPER
>and INK...], which emitted the requisite sequences for you.
Unfortunately they carried the idea of serial video attributes to the
high-resolution graphics, too. To set a foreground colour, one must insert a
byte into the graphics bitmap that eats up 6 pixels on the row (they appear
set in the new colour) and the byte colours all ON pixels to the right, until
another attribute byte or the end of the pixel row. This meant that
there was no way to plot a red pixel followed by a blue pixel and a green
pixel on the same row, but you could do it in the vertical direction!
>It also had the BASIC commands PING, ZAP, SHOOT and EXPLODE. Far, far
>out. I only ever in my life saw 2 cassettes of ORIC programs. One was
The sound facilities (produced using a dedicated chip) are definitely the
brightest side of the machine: 3-voice sound with volume control, noise
generator, different envelopes (there is a complicated BASIC command dedicated
to controlling it). Compare this to the beeper on the PC! Having simple BASIC
commands for the common sound effects instead of POKE:s (as on most of the
competing machines) was very nice for a novice. Unfortunately the hardware
interface to the sound chip was never documented, neither in the users manual
or in the various books on the machine. Same goes for the details of the
video mode switching (placing certain bytes to certain memory locations
makes the screen split between graphics and text modes in various proportions,
but I never could figure out the exact logic).
>the demo which came with the machine [and which had some fair animation
>in, actually -- a bird flying across the screen] and the other was the
>most steamingly turdacious piece of code I've ever experienced in my
>life -- a sort of assembler/debugger/editor called ORICADE that should
>have been persecuted under the Trades Descriptions Act.
There used to be several games, among them: a pretty good chess implementation
and HOBBIT, the same adventure-type game that was also available for the
Sinclair Spectrum (but for some reason the ORIC drew the illustrations
painfully slowly compared to the Sinclair version). The only language besides
BASIC that I have heard of was FIG FORTH and a rather braindamaged assembler
(no forward references to labels!) implemented in BASIC. I liked the FORTH, it
permitted *much* faster programs than the BASIC and allowed nice access to the
graphics and sound facilities.
Does anyone know if there ever were other languages? I remember reading about
two different floppy adapters, one manufactured by the ORIC manufacturer
itself and one by some other outfit. These would have permitted a C or Pascal
implementation.
I still have the machine. Maybe it will become a collectors' item in a
fifty years or so...
>When I heard that Tangerine had gone down the toilet shortly after I
>bought the ORIC, I was somewhat less than surprised :-)
Maybe they never recovered from the bad reputation that the bugs in ORIC-1
caused. But I am not really complaining, the ORIC-1 was very educational.
Along with helping to learn the basics of machine-code programming, interrupt
handlers and computer graphics, the machine gave a good lecture on the gap
between promises and reality in the computer business and the dangers of
version 1.0 software...
Anyone for an X-based ORIC-1 emulator, bugs and all? :-)
--
Erkki Ruohtula / Nokia Telecommunications Oy
e...@tele.nokia.fi / P.O. Box 33 SF-02601 Espoo, Finland
(My private opinions, of course.)
Jin S Choi
> Here is my terminfo entry for my dumb terminal program which uses the
> Pascal 1.1 entry point to the video firmware. The alternate character
> set does not quite work for drawing boxes (Apple's boxes are not centered).
>
> apple2e|apple //e 80 column card,
> am, bw, xon,
> cols#80, lines#24,
> acsc=+U\,H.J0N-KiC`[aVh]oLqS, bel=^G, civis=^F,
> clear=\f, cnorm=^E, cr=\r, cub1=\b, cud1=\n, cuf1=^\,
> cup=^^%p2%'\s'%+%c%p1%'\s'%+%c, cuu1=^_, ed=^K, el=^],
> home=^Y, ind=^W, kbs=\b, kcub1=\b, kcud1=\n, kcuf1=^U,
> kcuu1=^K, kdch1=^_, rev=^O, ri=^V, rmacs=^X^N,
> rmso=^N, sgr0=^X^N, smacs=^O\E, smso=^O,
>
Here's the termcap entries for the apple II from my /etc/termcap. It's
there because one of my friends did a lot of work for the NeXT apple II
emulator. This has actually been used to get emacs running under a
terminal program without vt100 emulation.
zh|appleII|apple ii plus:vs=\024\103\066:ve=\024\103\062:\
:am:co#80:ce=\035:li#24:cl=\014:bs:nd=\034:up=\037:ho=\E\031:pt:\
:cd=\013:so=\017:se=\016:cm=\036%r%+ %+ :is=\024T1\016:do=^J:kd=^J:\
:vb=\024G1\024T1:kr= :
# Gary Ford 21NOV83
# New version from ee178aci%sd...@SDCSVAX.ARPA Fri Oct 11 21:27:00 1985
zi|apple-80|apple II with smarterm 80 col:\
:am:bs:bt=^R:bw:cd=10*^K:ce=10^]:cl=10*^L:cm=^^%r%+ %+ :\
:co#80:cr=10*^M:do=^J:ho=^Y:le=^H:li#24:nd=^\\:up=^_:
#
# From Peter Harrison, Computer Graphics Lab, San Francisco
# ucbvax!ucsfmis!harrison .....uucp
# ucbvax!ucsfmis!harrison@BERKELEY .......ARPA
# "These two work. If you don't have the inverse video chip for the
# Apple with videx then remove the so and se fields."
zO|DaleApple|Apple with videx videoterm 80 column board with inverse video:\
:do=^J:am:le=^H:bs:cd=^K:ce=^]:cl=300^L:cm=^^%r%+ %+ :co#80:ho=^Y:\
:kd=^J:kl=^H:kr=^U:kh=^Y:\
:li#24:nd=^\:pt:so=^Z3:se=^Z2:up=^_:xn:
--
Jin Choi
j...@athena.mit.edu
Geoff Mccaughan
What a philistine. Everyone know's it's:
"Alas poor ORIC, I knew him Horatio..."
--
Geoff, Sysop Equinox (equinox.gen.nz) +64 (3) 3854406 [6 Lines]
"If you have to run heating in winter, you don't own enough computers."
Vote SPQR Ski Nix Olympica Freedom for Axolotls
Tor Iver Wilhelmsen
>In article <duck.739791417@nuustak> du...@nuustak.csir.co.za (Paul Ducklin) writes:
>>Thus spake tor...@flipper.pvv.unit.no (Tor Iver Wilhelmsen):
>>>Neither did I, but I used one occasionally, and owned an ORIC-1 (anyone
>>>remember those?)
>>
>>The first person I've ever heard of who's ever heard of ORICs and who
>>isn't me!
>
A pal of mine already had bought one... the alternative was a C64, but I
chose the ORIC.
>The ATMOS had a real keyboard. My ORIC-1 had some kind of calculator keys,
>although the keyboard was almost full-size. Another difference between the two
>is the ROM, the ATMOS version (v1.1) had most of the v1.0 bugs fixed.
>
Hard, plastic keys (white) on a black background. Rather slim
architecture. After a typing session, one usually had rectangular
depressions on the finger tips.
>
>I found the 2400bps speed quite reliable, if one used the same, good-quality
>recorder for saving and loading. The playback head alignment was crucial
>when exchanging tapes. I finally found that to read tapes saved on other
>machines, one must adjust the head alignment while playing the screeching
>through the speaker until it sounds as crisp as possible.
>
>One of the most irritating bugs in the v1.0 ROM prevented the BASIC LOAD
>command from correctly loading other than BASIC files into the memory. There
>were ways around this in machine code.
>
On the ORIC-1, you basically couldn't save or load properly anything else
than BASIC. The excellent adventure game "Zodiac" from Tansoft had machine
code routines to save and load variables (saving and restoring the game).
>Unfortunately they carried the idea of serial video attributes to the
>high-resolution graphics, too. To set a foreground colour, one must insert a
>byte into the graphics bitmap that eats up 6 pixels on the row (they appear
>set in the new colour) and the byte colours all ON pixels to the right, until
>another attribute byte or the end of the pixel row. This meant that
>there was no way to plot a red pixel followed by a blue pixel and a green
>pixel on the same row, but you could do it in the vertical direction!
>
But software developers did make some rather nice games (IJK and Tansoft
in particular) with almost no colour clashing (compare to early colour
games on the Spectrum). Anyone still remember "Xenon-1" and "Zorgon's
Revenge" ?
Actually, there were quite a few software houses back then, even some that
produced exclusively on the "dead" architectures (Dragon, ORIC, Acorn
Atom and Electron, Sinclair's NewBrain, Einstein etc.) Some house names
are Durell ("Harrier Attack"), IJK ("Xenon-1"), Salamander, A&F ("Chuckie
Egg"), Melbourne House, PSS, Level 9 ("Snowball"), Ultimate, Imagine...
the list goes on.
What all these have in common, is that they died. They either were bought
up, or fell under because the architectures they supported fell away.
Today, I think most software houses are owned by Br/oderbund and
Activision... *sigh*, today's youth don't know who Stavros Fasoulas (sp?)
was even...
>The sound facilities (produced using a dedicated chip) are definitely the
>brightest side of the machine: 3-voice sound with volume control, noise
>generator, different envelopes (there is a complicated BASIC command dedicated
>to controlling it). Compare this to the beeper on the PC! Having simple BASIC
>commands for the common sound effects instead of POKE:s (as on most of the
>competing machines) was very nice for a novice. Unfortunately the hardware
>interface to the sound chip was never documented, neither in the users manual
>or in the various books on the machine. Same goes for the details of the
>video mode switching (placing certain bytes to certain memory locations
>makes the screen split between graphics and text modes in various proportions,
>but I never could figure out the exact logic).
>
>There used to be several games, among them: a pretty good chess implementation
>and HOBBIT, the same adventure-type game that was also available for the
>Sinclair Spectrum (but for some reason the ORIC drew the illustrations
>painfully slowly compared to the Sinclair version). The only language besides
>BASIC that I have heard of was FIG FORTH and a rather braindamaged assembler
>(no forward references to labels!) implemented in BASIC. I liked the FORTH, it
>permitted *much* faster programs than the BASIC and allowed nice access to the
>graphics and sound facilities.
>
>Does anyone know if there ever were other languages? I remember reading about
>two different floppy adapters, one manufactured by the ORIC manufacturer
>itself and one by some other outfit. These would have permitted a C or Pascal
>implementation.
>
The ORIC disks were in the British 3" format as far as I know... I think I
have read of transfer rates of 250,000 baud, but I think that was a rather
steep aggression, especially since the Amstrad 3" stations (a few years
later) used 9,600. Apart from that, I think there was a Pascal compiler or
interpreter for the machine, on tape.
>Anyone for an X-based ORIC-1 emulator, bugs and all? :-)
>
Oh yes! Who cares about that crappy C64 anyway... :-)
>--
>Erkki Ruohtula / Nokia Telecommunications Oy
>e...@tele.nokia.fi / P.O. Box 33 SF-02601 Espoo, Finland
>(My private opinions, of course.)
Mr M J Brown
>>Neither did I, but I used one occasionally, and owned an ORIC-1 (anyone
>>remember those?)
I've got TWO! An Oric and an Atmos!!!! Hurray!
>
>>The ORIC-1 was awful and I loved it. Pity I sold it...
Sad Sad Sad. .... I still have mine from 1983, just after they came out.
Still use the thing for 6502 machine code (where I learned it)
>Wow. I had an ORIC ATMOS. Paid \Pounds 90 for it. It was total shite,
>if the truth be told -- but *great*.
Hmmm.. proof by contradiction?
>Redefinable character sets; sound
>[after a fashion]; plenty of memory [48K]; very small and light. It
>had a cassette interface which could do 300bps or 2400bps, but the 2400
>bps was not totally reliable. However, it was reliable enough to risk
>saving, say, 2 or 3 times at 2400bps -- and still faster than 300.
Aaah.. the old cassette reliablilty problems. Never had much trouble with that
because I always used to keep twiddling the azimuth on the deck used with the
machine. Course, disk drives are a damn sight better, even if only 160k ish big!
>It also had the BASIC commands PING, ZAP, SHOOT and EXPLODE. Far, far
>out. I only ever in my life saw 2 cassettes of ORIC programs. One was
>the demo which came with the machine [and which had some fair animation
>in, actually -- a bird flying across the screen] and the other was the
Aaah. that was the Atmos Demo, yes a very good piece of programming, and a
credit to the people who wrote the s/ware (Interrupt driven music too!)
You could actually stop the program and be listing it etc, whilst the music
would continue to play!
>Weird item from the manual in the version I had -- "This ROM release
>fixes a bug in Ver 1.0 which caused the CIRCLE command to produce
>ovals".
Hmmmm ... dunno bout that... They always look ok till you turn your head
sideways, then they look flattened, regardless of Oric/Atmos ROM
>When I heard that Tangerine had gone down the toilet shortly after I
>bought the ORIC, I was somewhat less than surprised :-)
Yes, real shame that, but so many computer companies did.
OK now hands up all those with an Enterprise 64/128 ??? Come on ... I can
see you hiding there ....
Now they are pretty *hot* machines for their time.... 256 colour graphics
up to 4 megs of ram , disk drive and mouse support almost from the off. ..
a sound chip which puts the Beep and Oric and Speccy to *shame*, graphics
were really good. Again, still gets used from time to time ....
=============================================================================
_/ _/ _/ _/ _/ _/_/_/_/ |
_/_/ _/_/ _/ _/_/ _/ | Michael Brown
_/ _/ _/ _/ _/ _/_/ |
_/ _/ _/ _/_/ _/ | m...@dcs.warwick.ac.uk
_/ _/ _/ _/ _/ _/_/_/_/ _/ | cs...@csv.warwick.ac.uk
=============================================================================
"It's one SML grep FOR man ....
one giant LOOP {FOR man -k -ind}" - /dev/null rm strong
=============================================================================
Also reachable at Michae...@f24.n258.z2.fidonet.org (slow!)
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Phillip Harvey-Smith
[Stuff deleted !]
>PS: And how much people will remember the 6809-based Dragon 32 ?
>
Yep, I have two of them ! One of which I recently (about a year and a
half ago) upgraded to 64K (this involved attacking it with a soldering
iron !). I also have twin 720k disk drives (using DragonDos), which I
also use with my QL, Spectrum and PC, and absolutly loads of software !
Does anyone know of a Dragon Emulator for the PC (well I can at least
dream !).
And yes I also remember the Oric, I had two friends who had them !
and I now have a friend with a Memotech MTX510 and another with a
Matel Aquarius(sp?).
Unfortunatly I've never owned a Jupiter Ace !
Phill the ancient computer collector(sp?), who also can't spell !
--
/----------------[ Courage is Grace Under Pressure. ]--------------------\
| Philip Harvey-Smith Have you come here for forgiveness ? |
| Alias Afra Lyon of Capella. Have you come to raise the dead ? |
| Have you come here to play Jesus |
| Mail Address af...@spuddy.uucp || To the lepers in your head ? |
| af...@uucp.spuddy -- U2, For Damia Gwyn-Raven. |
\---------------[ Until the end of the world, Haramis ]------------------/
BUCKLEY CHARLES RAY
Some puns are better left unsaid.
Have you no shame man? :-)
--
Charles Buckley buc...@ucsu.colorado.edu
It's turtles all the way down.
Just another West Virginia exile in the land of make believe.
Caesar si viveret, ad remum dareris.
Russell Schulz
> The command input always stripped spaces out of the line in the tokenising
> process, so getting extra spaces was never a problem. (But of course you
> could forget any heretical ideas you might have had about indenting your
> code!)
you could just add extra colons at the front (and maybe have a pretty-
printer that would change :: to two spaces)
10 FOR A=768 TO 793
20 ::READ D:POKE A,D
30 NEXT I
long ago, I used to consider having a license plate of `BNE 302'
(since so many tiny programs had the first two bytes of LDX #<constant>
(overwriteable, of course) and ended in DEX/BNE 302/RTS) but it'd
look too much like a non-custom one (and is prob'ly taken!)
--
Russell Schulz rus...@alpha3.ersys.edmonton.ab.ca ersys!rschulz Shad 86c
Paul Ducklin
[stuff about the ORIC brothers...]
> The only language besides
>BASIC that I have heard of was FIG FORTH and a rather braindamaged assembler
>(no forward references to labels!) implemented in BASIC. I liked the FORTH, it
>permitted *much* faster programs than the BASIC and allowed nice access to the
>graphics and sound facilities.
FORTH I was never aware of or the ORIC. I had an assembler which I wrote
myself in ORIC BASIC [you used the BASIC editor, starting your ASM code
at line 10000; you had full symbolic capability {there was a way to call
the BASIC interpreter from itself, thus parsing & executing a specially-
created expression buffer}; you could also {I seem to remember} load and
save the assembled code via the assembler before running it -- no tricks
required here as the LOAD/SAVE <memory-block> command worked perfectly
on the ATMOS].
The place I bought my ATMOS [now given away -- though I still have my
Acorn Atom, I think] from also had a garish fibreglass "workstation
pod", with indentatations in it for the ATMOS itself; your TV; a cassette
recorder and [I think] the optional plug-on disc drive. There were slots
and holes for your cabling! Ergonomics? This thing was worse than a Chev
Corvette ;-)
About the disc drive: once, whilst I was at University, someone came up to
me one Saturday to tell me there was a stallholder at the Jo'burg flea market
who had ORIC bits 'n pieces on sale *cheap*, so I should buy myself his
disc drive...turned out he had only an ATMOS unit up for grabs. So I never
did see an ATMOS drive.
I once built a 1-bit TTL to +/- 9V DC converter. With a little bit of
timer-driver code [done with my trusty assembler], I had an RS-232 port
on the ORIC, and succesfully used it to drive a Sharp typewriter I was
given. With another hack I wrote called ORICEDIT, I once used this system
to churn out an essay ["term paper"?] for my wife for a course she was
doing at the time.
Afterwards [if the truth be told] I realised that it would have been much
less effort for me to have written out the paper longhand...though it
wouldn't have looked as spiffing! Painful bit was taking the output of
the typewriter [thermal] to a photocopier to duplicate. You had to submit
a copy -- otherwise, if the lecturer/bureaucrat/potential employer left
your beautiful missive in the sun, it would rapidly fade to black :-)
A Myles
: Now they are pretty *hot* machines for their time.... 256 colour graphics
: up to 4 megs of ram , disk drive and mouse support almost from the off. ..
: a sound chip which puts the Beep and Oric and Speccy to *shame*, graphics
: were really good. Again, still gets used from time to time ....
Did the enterprise actually make it out? The last I ever heard of it
back about 1984, it was looking a bit unlikely (Maybe Clive was contracted to
fix the delivery dates for it. hahaha!)
Still, the 2-page full-colour advert for it used to look well impressive.
Some-one also mentioned the MTX500 range... did they ever live up to the
claims that they were pretty hot machines for the time?
--
He's cute, he's sooooo bright, he lies... Andrew Myles, aj...@ee.edinburgh.ac.uk
Integrated Systems Group (the boys to entertain yoooou) (Caledonia)031 650 5665
-----
Yes, I am into flagellation. My favourite is a Jolly Roger. (oooer, Missus...)
Magnus Olsson
>Thus spake tor...@flipper.pvv.unit.no (Tor Iver Wilhelmsen):
>>Neither did I, but I used one occasionally, and owned an ORIC-1 (anyone
>>remember those?)
>
>The first person I've ever heard of who's ever heard of ORICs and who
>isn't me!
You can add me to your list as well... I've never seen one of the beasts
in real life, but I've certainly heard of them.
BTW, the most memorable reference to an Oric I've seen wasn't very
flattering. In the write-up of a game for the Acorn Atom ("The Quest"
by Nick Foale), one of the monsters was described as "somewhat like a
deranged, Oric-owning traffic warden"... :-)
Magnus Olsson | \e+ /_
Department of Theoretical Physics | \ Z / q
University of Lund, Sweden | >----<
mag...@thep.lu.se, the...@selund.bitnet | / \===== g
PGP key available via finger or on request | /e- \q
Mr M J Brown
>
>Did the enterprise actually make it out? The last I ever heard of it
>back about 1984, it was looking a bit unlikely (Maybe Clive was contracted to
>fix the delivery dates for it. hahaha!)
Thankfully, Clive was *not* involved. It may not have got out at all with
him and the Enterprise team working together!
Hehe, ahem, well it did *sort of* get out :-)
It was late, delayed, and delayed again, but eventually did surface after
a few name changes "Samurai", then "Elan enterprise", "Flan Enterprise"
and finally just "ENTERPRISE"
Also a colour change in the process, from grey to multicolor RGB case!!
Wim Coekaerts
I learned to work with... The only thing I didn't like about it, was the
keyboard... was a pain to type fast on that thingy, even the spectrum's key-
board was easier (IMHO)
Hmmm I do remember the game Xenon-1... Was really hooked on that thing :-)
hehehe :-) anyway, just to say that it was a cool thing, that oric :-)
loved it.
Wim
Mr M J Brown
For all those Oric Users out there, here is a useful bit of information :-
OUM, Oric User Monthly is a magazine produced/distributed for Oric Enthusiasts.
If you are not getting this magazine, and have an Oric somewhere tucked away,
write to
Dave Dick
65 Barnard Crescent
Aylesbury
Bucks
HP21 9PW
England
The magazine has 110 readers at present, 70 issues under the bridge and still
going strong.
There is also an Oric Bulletin Board. The number is 0223 835171, from 10pm
to Midnight on Mon Thu and Fri at the moment. Not sure of speeds supported,
but give it a call if you can. Oric Software etc for download, and also
contact with other users who can solve problems.
Enterprise users, an address to get in contact with is
Peter Mundin
Final Frontier
17 Coronation Ave
Mile Oak
Tamworth
Staffs
Phone 0827 250457
Peter deals with various hardware/software, and seems to be about the only
person left in the UK who deals with Enterprise stuff. There was a user group
but it seems to have been suspended over here in the UK.
Sverker Wiberg
The Spectrum didn't have separate text and graphics screens, everything
went to a 256x192 bitmapped display. The weird part was the mapping
of RAM to screen lines. The first 32 bytes of screen memory held line 0,
the next 32 held line 8, the next 32 line 16 etc. This arrangement
continued upto line 56. The 32 bytes after that held line 1, the next
32 line 9 and so on upto 57, where it went back to line 2. When all
of the lines 0-63 were done it repeated this with 64-127, then 128-191.
I remember, when I began exploring my (then) new XTclone whith 8086
assembler and hires CGA (320x400x2), that the bitmap layout was a
wonder of sanity compared to Spectrum's. the scanlines were ordered 1,
3, 5,..., 317, 319, 2, 4, 6,..., 318, 320...I think...
--
Sverker Wiberg <sver...@student.docs.uu.se>
o===[---- Purgamentum init, exit purgamentum
Ross Smith
ObFolklore: The Oric was named after the computer Orac in the TV series
`Blake's 7'.
--
... Ross Smith (Wanganui, New Zealand) ... al...@acheron.amigans.gen.nz ...
"Where are we going?" "Planet Ten!"
"When?" "REAL SOON!"
Jim Finnis
s...@bach.cefriel.it (Mitraglia) burbled:
> <stuff bout ORICS>
>
Does anyone remember a surreal game called "Don't Press the Letter Q"? My SO
had an ORIC when she was younger, and she *raves* about this game all the time.
Apparently, it was an arcade game that randomly generated the characteristics
of the levels - like "space invaders, with platforms, and a centipede, and
this set of sprites". You weren't to press the letter Q, because that
would just quit the game...
--
-----------------------------------------------------------------------------
Jim Finnis, | Unit 6A, Science Park, Aberystwyth, Dyfed, SY23 3AH
Clef Digital Systems |
cl...@aber.ac.uk | Tel.: 0970 626601 Overseas: +44 970 626601
Christopher Jd Samuel
s...@bach.cefriel.it (Mitraglia) doodled:
> >The first person I've ever heard of who's ever heard of ORICs and who
> >isn't me!
>
> I never bought an ORIC, but I knew it.
Same here, but do you remember the Jupiter Ace that had FORTH as it's
language of choice ?
> PS: And how much people will remember the 6809-based Dragon 32 ?
Me, me [waves hand in air], and I even got to use one a couple of times.
I saw (but never tried) it's successor, the Dragon 64, a 64K machine
that flopped. Unfortunate really, as the manufacturer was (I *think*)
the only Welsh computer manufacturer yet..
> PS2: Anybody on the Net ever owned an Apricot ??
Not owned one, but we had a few here at Aberystwyth doing service as
terminals. They had these wonderful keyboards that were IR linked to be
base unit, which meant that people nicked that batteries out of them all
the time. This IR link, coupled with the fact that there was a RESET
button on the keyboard meant that it was also possible to stand at the
back of a terminal room with one of these and 'spray' the room with the
RESET button held down....... not that I ever did you understand, I
just knew the wrong people (Hi Alan).
Cheers,
Chris
--
Christopher Samuel, Computer Unit, U.W Aberystwyth, Aberystwyth, WALES
E-mail: c...@aber.ac.uk PGP 2.1 public key available on request
"Some say the gods are a myth, - The Waterboys
but guess who I've been dancing with." "The Return of Pan"
Christopher Jd Samuel
cs...@csv.warwick.ac.uk (Mr M J Brown) doodled:
> OK now hands up all those with an Enterprise 64/128 ??? Come on ... I can
> see you hiding there ....
>
> Now they are pretty *hot* machines for their time.... 256 colour graphics
> up to 4 megs of ram , disk drive and mouse support almost from the off. ..
> a sound chip which puts the Beep and Oric and Speccy to *shame*, graphics
> were really good. Again, still gets used from time to time ....
Were they the white ones with the built in joystick on the right (?)
hand side ??
I vaguely remember *one* machine like that from my childhood, but my
first machine was a VIC-20, which was fun to play with, but eventualy my
brother got a CBM-64... Actually, I'd gone out and bought Elite for it
before my bro even had bought the 64.. :-)
Christopher Jd Samuel
af...@spuddy.uucp (Phillip Harvey-Smith) doodled:
> And yes I also remember the Oric, I had two friends who had them ! and
> I now have a friend with a Memotech MTX510 and another with a Matel
> Aquarius(sp?).
Ahh.. the MTX510, I remember them, a cool black case from the little I
remember. Acutally, they were the first computer I (literally) dreamed
of owning, quite a disappointment when I woke up! Was it the Aquarius
that had the add on home computer called the Adam (or suchlike) or was
that the Collecovision (spelling?).
Chris, who can't spell (or at least type)
Paul Sanders
> In article <1993Jun11....@cdc486.cdc.polimi.it>
> s...@bach.cefriel.it (Mitraglia) doodled:
>
>> >The first person I've ever heard of who's ever heard of ORICs and who
>> >isn't me!
>>
Me me me me me! It was 6809E, actually, but who am I to nitpick when I
don't even know what difference that E made. I had a Dragon 32 and
later a Dragon 64. It was a cool machine - a colour TRS-80 for half
the price.
Oh how I cried when Mattel stopped making them
Paul.
--
Paul Sanders psan...@srd.bt.co.uk Tel: +44 473 645716
Software Research, BT Laboratories, Martlesham Heath IPSWICH IP5 7RE
Mr M J Brown
>
>> OK now hands up all those with an Enterprise 64/128 ??? Come on ... I can
>> see you hiding there ....
>>
>> Now they are pretty *hot* machines for their time.... 256 colour graphics
>> up to 4 megs of ram , disk drive and mouse support almost from the off. ..
>> a sound chip which puts the Beep and Oric and Speccy to *shame*, graphics
>> were really good. Again, still gets used from time to time ....
>
>Were they the white ones with the built in joystick on the right (?)
>hand side ??
Yep, that's the one. Handy for editing, you could just bring your hand sharply
right to left and clonk it to delete! ...
Bernd Meyer
>m...@castle.ed.ac.uk (M Gordon) writes:
>The Spectrum also had some pretty evil hardware. In a scheme similar to the
>Amiga's chip/fast RAM, there was 32K of fast memory that only the processor
>could access (the only place you'll ever see 32K*1 DRAM), and 16K shared
Nah! Remember Memotech's MTX500 and MTX512-series! The 500 had 8 32k*1 chips
in it. The boards design gave me a clue that in the good ole days of
64k-chips, they didn't throw away chips with just a few defects, but labeled
them accordingly and sold them. If I remember correct, you could make the
board use
a) the first 32k of each chip
b) the second 32k of each chip
c) the first 16k of both halfes (i.e., 0-16383 and 32768-49151)
d) the second 16k of both halfes
If you talk about this machine further, you may discover I LOVE it's design!
>between the processor and video. Any normal design would place a heap of
>buffers between the two, so video addresses and data placed on that half of
>the bus wouldn't intefere with processor address and data. No no no. Far too
>expensive. They used resistors. When the video wasn't doing anything, it
Another not so unique hack! I believe the Spectrum and the VZ-200/Laser
110/210/310 series used the same video chip, and they definitly used the
same way to interface them (and hey, it worked, it was cheap, and it was
much simpler than determining the state of all those buffers at any
moment!).
At least I prefer this over the C64 way :-)
BTW, the Laser-series had only 2k of video ram and so the video chip wasn't
even half used to its limits. Not expandable, though :-((
>went tri-state, and the processor signals could make it through the
>resistors to that half of the bus. When it was accessing RAM, you'd get
>different voltages on either end of the resistor - a small current running
>through it, but no real problem.
Bernie
David Hembrow
>110/210/310 series used the same video chip, and they definitly used the
>same way to interface them (and hey, it worked, it was cheap, and it was
>much simpler than determining the state of all those buffers at any
>moment!).
>At least I prefer this over the C64 way :-)
>BTW, the Laser-series had only 2k of video ram and so the video chip wasn't
>even half used to its limits. Not expandable, though :-((
Can't be true. The spectrum ULA was Sinclair's own design and had one
video mode which used 6912 bytes of memory. This chip was most of the
guts of a spectrum so if you used one you would have a spectrum clone.
Bernd Meyer
I don't know about it, but what was said about the chip in the Spectrum was
exactly what itwas like in the VZ-200 (except that the video chip wouldn't
stop the clock of the CPU, but would leave like a gentleman in cases of
conflict on the busses - thus leading to things later known as "CGA snow").
And the video chip wasn't used to what it could be (maybe they bought them
from Sinclair and got this inforced on them?), and there was no way to add
extra Video memory, plus some of the mode control lines were hardwired to
ground. Real shame!
In Germany, you could by add ons with a complete video chip and more Ram
(and thus higher resolution graphics) from some private vendors. Never saw
one, though.
Bernie (who still has to hack his VZ-200 back into life again)