17 May
2000
17 May
'00
3:04 p.m.
On May 17, 13:06, Vintage Computer GAWD! wrote:
into
On Wed, 17 May 2000, Pete Turnbull wrote:
> Yes, probably :-) Since you wouldn't need much code, and nothing on a
> standard Apple uses interrupts, you could go one further and make it a
> time-sliced system instead of a cooperative one, with a very simple
circuit
> (not much more than a 555 timer, though you might
want it on a card
with a
PROM to hold
the code).
I considered this. An easier way to do this is to copy the BASIC ROM RAM in the upper 16K bank of memory and then modify
the interpreter to
switch after the execution of each BASIC program line.
Depends on whether you prefer hardware to software, I guess :-) Modifying
BASIC in a language card also has the advantage that it only tries to
switch when it's actually executing BASIC (rather than some DOS routine or
something you've BRUN) but I suspect that after-every-line is too often --
you'd spend a lot of time (proportionately speaking) context switching.
And it would be irregular; a multi-statement line encompassing a loop will
take much longer than a simple statement.
--
Pete Peter Turnbull
Dept. of Computer Science
University of York
17 May
17 May
4:03 p.m.
New subject: VAX 4000 panel bulkhead compatibility?
As I mentioned earlier I've got a BA213 "MicroVAX 3400" that has had its
CPU upgraded to a KA660 (VAX 4000/200). I'm trying to get networking working.
I have available MULTINET and UCX as software, currently Multinet is
installed under a 30 day evaluation PAK. @MULTINET:START_MULTINET runs but
MULTINET CHECK claims that my default router is unreachable.
EZA0: is plugged through an ethernet tranciever into a hub. I've tried the
SQE switch on both positions (I can never remember if hubs _want_ heart
beats or not).
I have two other systems connected to that Hub, one a VAX 4000/300 with
VMS/Multinet and one a Vaxstation 3100/M76 with NetBSD. I can telnet to
either of them from the main network so I'm pretty sure the hub is working.
Q1: Is the CPU "bulkhead" for the 4000/200 compatible with the CPU bulkhead
for the 3400? It is the "one ribbon cable" variety (rather than the
two cables the the KA630,50,and 55 use)
Q2: Which way _should_ the SQE switch be set?
Q3: Does Multinet do Echoreply? Pings seem to fall into a black hole.
--Chuck
5:34 p.m.
I have a prototype multitasking operating system in 6502 machine language
for the Atari 8-bit series machines. Might be useful if I get the gist of
what this topic is about. The main purpose was to run several BASIC
programs simultaniously and give each a timeslice. The timeslice for each
task is adjustable.
If true timeshareing is not required then I'd look to Tom Hunt for his
AMAZING program "SNAPSHOT". Snapshot swaps images of ram to disk and
produces the effect of multitasking but the tasks on disk are of course
halted.... It is incredibly compatible. Tom Hunt is a God on 6502. He
mainly wrote in ACTION! - a C-like language unique to the Atari from OSS
(Optimized System Software - they used to be Sheperdson Microsystems and
wrote Atari Basic in addition to many other things in the 8-bit world).
Action had the benefit of a runtime package for distribution and very fast
program execution when compared to most other languages for the Atari.
Action! programs ran at near machine code speed.
--
-----------------------------------------------------------
Jeffrey S. Worley
Complete Computer Services
30 Greenwood Rd.
Asheville, NC 28803
828-274-5781 0900-1800 weekdays
Who is General Failure and why is he reading my hard disk?
Technoid(a)Cheta.net
-----------------------------------------------------------
6:13 p.m.
New subject: Univac Lamp interesting piece
Even though its on epay and the reserve is $10K, this *is* an
interesting piece. Its a lamp constructed from pieces of the
technology that went into the Univac (model 70), according to
the seller. Looks like technology around about 1970, with
a combination of core and ICs.
http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=334627365
Any opinions on the authenticity of this item?
This reminds me a little of some sculptures of animals that were
constructed in the late 60s/early 70s from electronic components,
and were part of an advertising for some company [Honeywell?].
Anybody know anything about them? Are there pics on the web?
18 May
18 May
4:31 a.m.
New subject: Univac Lamp interesting piece
At 11:13 PM 5/17/00 -0400, John Lewczyk wrote:
Even though its on epay and the reserve is $10K, this
*is* an
interesting piece.
And the seller has those charming qualities of only being able
to type in upper case, sprinkled with spelling errors. I guess
the $10,000 price is based on a 2/3 reduction of the "former
shipping supervisor for Univac," who estimated the original
cost of goods used to construct the lamp.
www.sanfordandson.com, indeed!
- John
6:22 a.m.
New subject: Just when you thought it was safe...
... it is that time of year yet again!
The n'th twice-annual (and first of the new millennium) CP/M Users Group
NorthWest Swap Meet is almost upon us!
Date: 10-June-2000 (Saturday)
Place: Tigard Senior Center - Tigard, Oregon
Time: 9am to 2pm (official) 7am to whenever (realistically)
Worth it? Well, yes there is a lot of 'PC' junk running around... but at
the last meet was seen a nearly pristine AIM-65 in ORIGINAL box with all
ORIGINAL docs! (even the original sales receipt) And other amazingly
classic items for nabbing! So... you decide! (I know who got it... and
I'm not telling!)
...and if you are worried about a possible lack of classic goodies...
BRING SOME!
Why the "n'th"? - Well... it's been so long since I (co-)founded the
group, we have all long ago lost count...
Better directions: Soon to come... Would GPS coordinates help for the
true tech-heads amoungst us?
Be there or be asymmetrically non-orthagonal!
-jim
---
jimw(a)computergarage.org || jimw(a)agora.rdrop.com
The Computer Garage - http://www.computergarage.org
Computer Garage Fax - (503) 646-0174
8:27 a.m.
New subject: Just when you thought it was safe...
On Thu, May 18, 2000 at 08:22:35AM -0700, James Willing wrote:
Be there or be asymmetrically non-orthagonal!
Oh, so people who do not go are not square, so people who go are...ummm...
what? :-) Round? At a hamfest, I imagine so.
--
_______ Shawn T. Rutledge / KB7PWD ecloud(a)bigfoot.com
(_ | |_) http://www.bigfoot.com/~ecloud kb7pwd(a)kb7pwd.ampr.org
__) | | \________________________________________________________________
Get money for spare CPU cycles at http://www.ProcessTree.com/?sponsor=5903
11:04 a.m.
New subject: Univac Lamp interesting piece
At 11:13 PM 5/17/00 -0400, John Lewczyk wrote:
That sure sounds like Barry Goetz, and he is VERY serious about his "art".
Even though its on epay and the reserve is $10K,
this *is* an
interesting piece.
And the seller has those charming qualities of only being able
to type in upper case, sprinkled with spelling errors. I guess
the $10,000 price is based on a 2/3 reduction of the "former
shipping supervisor for Univac," who estimated the original
cost of goods used to construct the lamp.
www.sanfordandson.com, indeed!
- John 
8:33 a.m.
New subject: Univac Lamp interesting piece
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 431 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000518/15392e19/at…
17 May
17 May
6:59 p.m.
On Wed, 17 May 2000 technoid(a)cheta.net wrote:
I have a prototype multitasking operating system in
6502 machine language
for the Atari 8-bit series machines. Might be useful if I get the gist of
what this topic is about. The main purpose was to run several BASIC
programs simultaniously and give each a timeslice. The timeslice for each
task is adjustable.
This is indeed what we are talking about. Sounds cool!
If true timeshareing is not required then I'd look
to Tom Hunt for his
AMAZING program "SNAPSHOT". Snapshot swaps images of ram to disk and
Slow?
produces the effect of multitasking but the tasks on
disk are of course
halted.... It is incredibly compatible. Tom Hunt is a God on 6502. He
mainly wrote in ACTION! - a C-like language unique to the Atari from OSS
(Optimized System Software - they used to be Sheperdson Microsystems and
wrote Atari Basic in addition to many other things in the 8-bit world).
Sounds familiar. Didn't they also write DOS for the Apple ][? I've heard
the names before (Sheperdson and OSS) but can't quite place what products
I associate with them. I know there was a company that developed
primarily for the Atari but also did Apple DOS. I have their website
linked from the VCF links page but am too lazy to go looking.
Action had the benefit of a runtime package for
distribution and very fast
program execution when compared to most other languages for the Atari.
Action! programs ran at near machine code speed.
Interesting!
18 May
18 May
7:06 a.m.
On 17 May 2000, at 20:59, Vintage Computer GAWD! wrote:
Sounds familiar. Didn't they also write DOS for
the Apple ][? I've
heard the names before (Sheperdson and OSS) but can't quite place what
products I associate with them. I know there was a company that
developed primarily for the Atari but also did Apple DOS. I have
their website linked from the VCF links page but am too lazy to go
looking.
Yes, they wrote the original DOS for the Apple II. Then went on to
do Atari BASIC and Atari DOS and many other pieces of software
for Atari. I also have a copy of CP/A+ which is an Apple II OS they
wrote which is very similar to their OS/A+ for the Atari. I've always
had a thing for collecting odd-ball operating systems.
-----
David Williams - Computer Packrat
dlw(a)trailingedge.com
http://www.trailingedge.com
8:40 a.m.
On 18 May 2000, at 8:40, Vintage Computer GAWD! wrote:
On Thu, 18 May 2000, David Williams wrote:
I'll see about digging it up. Since the Apple II was one of my
favorites I tend to have all of my Apple stuff at home unlike some of
my systems which are in storage. I can ShrinkIt but not the
manuals of course. I have been thinking of scanning them though.
IIRC, it came with a version of BASIC based on the version they
wrote for the Atari. It might be 13 sector though, I don't recall. I'll
let you know. Wait... I seem to recall it used a different layout than
Apple DOS, more like the system used with the Atari DOS. 128
byte sectors as such.
I also had the Apex OS with the XPL0 language. Never did get a
copy of the version of Focal for Apex but I wanted it. That was 13
sector when I picked it up but I was able to hack together a 16
sector version.
-----
David Williams - Computer Packrat
dlw(a)trailingedge.com
http://www.trailingedge.com
for Atari. I also have a copy of CP/A+ which is
an Apple II OS they
wrote which is very similar to their OS/A+ for the Atari. I've
always
Ooh! I'd love to get a copy of that! Can you ShrinkIt and e-mail it
to me??
4:10 a.m.
You may find that your multitasking effort works better if you don't accept
a time-slice when it's offered unless you're ready for it. Many times
(particularly with the rather slow disk I/O, etc) you are I/O bound or
waiting for another process to complete, it's better all around if you give
back the time-slice if you can't use it. If the time slice is small (e.g.
1/60 sec or so) it won't matter so much, but if it's long, i.e. 1/10 sec, or
so, you may want to avoid wasting it.
Dick
----- Original Message -----
From: <technoid(a)cheta.net>
To: <classiccmp(a)classiccmp.org>
Sent: Wednesday, May 17, 2000 8:34 PM
Subject: Re: Cool AppleSoft BASIC trick I never thought of before
I have a prototype multitasking operating system in
6502 machine language
for the Atari 8-bit series machines. Might be useful if I get the gist of
what this topic is about. The main purpose was to run several BASIC
programs simultaniously and give each a timeslice. The timeslice for each
task is adjustable.
If true timeshareing is not required then I'd look to Tom Hunt for his
AMAZING program "SNAPSHOT". Snapshot swaps images of ram to disk and
produces the effect of multitasking but the tasks on disk are of course
halted.... It is incredibly compatible. Tom Hunt is a God on 6502. He
mainly wrote in ACTION! - a C-like language unique to the Atari from OSS
(Optimized System Software - they used to be Sheperdson Microsystems and
wrote Atari Basic in addition to many other things in the 8-bit world).
Action had the benefit of a runtime package for distribution and very fast
program execution when compared to most other languages for the Atari.
Action! programs ran at near machine code speed.
--
-----------------------------------------------------------
Jeffrey S. Worley
Complete Computer Services
30 Greenwood Rd.
Asheville, NC 28803
828-274-5781 0900-1800 weekdays
Who is General Failure and why is he reading my hard disk?
Technoid(a)Cheta.net
-----------------------------------------------------------
4:25 a.m.
It was thus said that the Great Richard Erlacher once stated:
You may find that your multitasking effort works better if you don't accept
a time-slice when it's offered unless you're ready for it. Many times
(particularly with the rather slow disk I/O, etc) you are I/O bound or
waiting for another process to complete, it's better all around if you give
back the time-slice if you can't use it. If the time slice is small (e.g.
1/60 sec or so) it won't matter so much, but if it's long, i.e. 1/10 sec, or
so, you may want to avoid wasting it.
Generally in a multitasking system with timeslicing, there are two queues
(or lists)---one for processes that are running, and another one for
processes that are waiting for something (usually I/O to complete). The
code that manages the tasks take the next task on the run queue and
dispatch it.
When an event one of the processes on the wait queue has happened, it is
then moved from the wait queue to the run queue. When a process makes a
request that may take awhile, it is then moved from the run queue to the
wait queue. There is no need for the process to give up its slice if its
waiting for something---all that happens in the system.
-spc (Have compiler, will program)
7:41 a.m.
Generally in a multitasking system with timeslicing,
there are two queues
(or lists)---one for processes that are running, and another one for
processes that are waiting for something (usually I/O to complete). The
code that manages the tasks take the next task on the run queue and
dispatch it.
That is one way. the other is one task list with a bitwise flag
indicating that tasks status. A task is removed from the list when
complete and entered on the list at startup. The first(or last)
task on the list is one permanent one usually a null task. The priority
can be stored in the tasklist as well (if not round robin).
I did this on my first z80 multitasking system. The task list included
queued IO as well so that things like testing to see if a task could
continue from a blocked-IO state was possible.
Allison
4:26 a.m.
Yes, having the app falg "blocked waiting IO" is important if you want the
best efficientcy. The difficult part is sometimes determining that and
keeping it sane.
Allison
On Thu, 18 May 2000, Richard Erlacher wrote:
You may find that your multitasking effort works
better if you don't accept
a time-slice when it's offered unless you're ready for it. Many times
(particularly with the rather slow disk I/O, etc) you are I/O bound or
waiting for another process to complete, it's better all around if you give
back the time-slice if you can't use it. If the time slice is small (e.g.
1/60 sec or so) it won't matter so much, but if it's long, i.e. 1/10 sec, or
so, you may want to avoid wasting it.
Dick
----- Original Message -----
From: <technoid(a)cheta.net>
To: <classiccmp(a)classiccmp.org>
Sent: Wednesday, May 17, 2000 8:34 PM
Subject: Re: Cool AppleSoft BASIC trick I never thought of before
I have a prototype multitasking operating system
in 6502 machine language
for the Atari 8-bit series machines. Might be useful if I get the gist of
what this topic is about. The main purpose was to run several BASIC
programs simultaniously and give each a timeslice. The timeslice for each
task is adjustable.
If true timeshareing is not required then I'd look to Tom Hunt for his
AMAZING program "SNAPSHOT". Snapshot swaps images of ram to disk and
produces the effect of multitasking but the tasks on disk are of course
halted.... It is incredibly compatible. Tom Hunt is a God on 6502. He
mainly wrote in ACTION! - a C-like language unique to the Atari from OSS
(Optimized System Software - they used to be Sheperdson Microsystems and
wrote Atari Basic in addition to many other things in the 8-bit world).
Action had the benefit of a runtime package for distribution and very fast
program execution when compared to most other languages for the Atari.
Action! programs ran at near machine code speed.
--
-----------------------------------------------------------
Jeffrey S. Worley
Complete Computer Services
30 Greenwood Rd.
Asheville, NC 28803
828-274-5781 0900-1800 weekdays
Who is General Failure and why is he reading my hard disk?
Technoid(a)Cheta.net
-----------------------------------------------------------
7:28 a.m.
You may find that your multitasking effort works
better if you don't accept
a time-slice when it's offered unless you're ready for it. Many times
(particularly with the rather slow disk I/O, etc) you are I/O bound or
waiting for another process to complete, it's better all around if you give
back the time-slice if you can't use it. If the time slice is small (e.g.
1/60 sec or so) it won't matter so much, but if it's long, i.e. 1/10 sec, or
so, you may want to avoid wasting it.
I don't think this is particularly a problem on the Apple ][ series. IIRC,
all I/O is CPU intensive, so giving up the CPU during I/O will likely cause
the I/O to fail. Am I getting old? The details of the Disk ][ interface
are only faintly registering on my brain. Wasn't the input a bit at a time
with a software wait between bits, or am I confusing that with the tape
interface with its half-hardware/half-software 1-bit ADC?
Of course, none of this is a concern with cooperative multitasking of BASIC
programs but if someone implements an interupt generator on a ][ for
multitasking purposes, it could become a concern.
Eric
7:52 a.m.
I don't think this is particularly a problem on
the Apple ][ series. IIRC,
all I/O is CPU intensive, so giving up the CPU during I/O will likely cause
the I/O to fail. Am I getting old? The details of the Disk ][ interface
are only faintly registering on my brain. Wasn't the input a bit at a time
with a software wait between bits, or am I confusing that with the tape
interface with its half-hardware/half-software 1-bit ADC?
Common thing with apples, many other systems that were minimalist too.
Obviously for those and a great many others part of timeslicing has to
be doing IO (aka an IO timeslice). This can seriously hurt system
performance as you really get to see howmuch cpu is used in isolation from
all the pending tasks.
Of course, none of this is a concern with cooperative
multitasking of BASIC
programs but if someone implements an interupt generator on a ][ for
multitasking purposes, it could become a concern.
Big time. ;)
Generally what seperated the generic systems of the time from those that
could do serious workloads was the needed hardware support for interrupts.
With even a basic periodic interrupt it was possible to do background
tasks (keyboard scan, serial IO) that didn't appear to need to wait for
the application. To me one of the most annoying this was waiting for it
to ask for input but not accept type ahead!
Allison
8:01 a.m.
On Thu, 18 May 2000, Eric J. Korpela wrote:
I don't think this is particularly a problem on
the Apple ][ series. IIRC,
all I/O is CPU intensive, so giving up the CPU during I/O will likely cause
the I/O to fail. Am I getting old? The details of the Disk ][ interface
are only faintly registering on my brain. Wasn't the input a bit at a time
with a software wait between bits, or am I confusing that with the tape
interface with its half-hardware/half-software 1-bit ADC?
Woz basically left a lot to software. He figured if anything could be
done in software then thjere was no need to implement it in hardware. As
such, the disk reads & writes are very CPU intensive.
Of course, none of this is a concern with cooperative
multitasking of BASIC
programs but if someone implements an interupt generator on a ][ for
multitasking purposes, it could become a concern.
Very much so. In fact it would turn this whole exercise into work, which
is not fun.
10:54 a.m.
Most other-than-IO functions performed during I/O such as graphics, sound,
etcetera on the Atari 8-bits utilized the fact that for 1 60th of a second
the screen is not painted. While the 'vertical blank' was occurring you
had several cpu cycles available. If you wrote very tight code you could
do a lot in those few cycles. On the Atari this was accomplished by GTIA
'display lists' which are programs for the GTIA coprocessor.
Can the Apple II be convinced to perform this feat? I have allways
wondered but not passionatly enough to investigate about the Apple II
series i/o scheme.
In <200005181628.JAA12478(a)islay.ssl.berkeley.edu>du>, on 05/18/00
at 03:54 PM, "Eric J. Korpela" <korpela(a)albert.ssl.berkeley.edu> said:
I don't think this is particularly a problem on the
Apple ][ series.
IIRC, all I/O is CPU intensive, so giving up the CPU during I/O will
likely cause the I/O to fail. Am I getting old? The details of the Disk
][ interface
are only faintly registering on my brain. Wasn't the input a bit at a
time with a software wait between bits, or am I confusing that with the
tape interface with its half-hardware/half-software 1-bit ADC?
Of course, none of this is a concern with cooperative
multitasking of
BASIC programs but if someone implements an interupt generator on a ][
for multitasking purposes, it could become a concern.
Eric
--
-----------------------------------------------------------
Jeffrey S. Worley
Complete Computer Services
30 Greenwood Rd.
Asheville, NC 28803
828-274-5781 0900-1800 weekdays
Who is General Failure and why is he reading my hard disk?
Technoid(a)Cheta.net
-----------------------------------------------------------
11:48 a.m.
On Thu, 18 May 2000 technoid(a)cheta.net wrote:
Most other-than-IO functions performed during I/O such
as graphics, sound,
etcetera on the Atari 8-bits utilized the fact that for 1 60th of a second
the screen is not painted. While the 'vertical blank' was occurring you
had several cpu cycles available. If you wrote very tight code you could
do a lot in those few cycles. On the Atari this was accomplished by GTIA
'display lists' which are programs for the GTIA coprocessor.
Can the Apple II be convinced to perform this feat? I have allways
wondered but not passionatly enough to investigate about the Apple II
series i/o scheme.
The Apple ][ has an address that you can monitor that tells you when it's
in the vertical blanking interval. People have done some neat stuff by
timing their code around the interval, such as mixing all three graphics
modes (text, lo-res and hi-res) on the same screen.
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
1:59 p.m.
On Thu, 18 May 2000, Vintage Computer GAWD! wrote:
The Apple ][ has an address that you can monitor that tells you when it's
in the vertical blanking interval. People have done some neat stuff by
timing their code around the interval, such as mixing all three graphics
modes (text, lo-res and hi-res) on the same screen.
Most of these tricks were described in the following book (if you can
get your hands on it, it's long since gone out of print):
Lancaster, Don. Enhancing your Apple II /, by Don Lancaster ; [illustrated
by T.R. Emrick]. 1st ed. Indianapolis, IN : H.W. Sams, c1982-<c1985
Apple II's needed a simple hardware hack (a couple of wires or simple
components) in order to make one of the hardware memory addresses
correspond to the state of the vertical blanking interval (it would either
go high or low when vertical blanking was going on). IIe's and IIc's had a
memory location (hex C013?) that does that for you, no hardware hack
required. (Although, $C013 behaved in the opposite manner than Lancaster's
hack did--perhaps $C013 went high when Lancaster's memory location went
low and vice versa, so Lancaster's programs had to be modified a slight
bit in order to work).
In any event, once you had the vertical blanking information, you could
write machine language programs that would switch between Apple graphic
modes just about anyplace on the screen (within limits). You were more or
less limited to static displays because of the timimg requirements, but
you could still do some interesting stuff. I typed in a few of the
programs, and still have them sitting around on a disk if anyone is
curious...
3:35 p.m.
On Thu, 18 May 2000, Charles P. Hobbs (SoCalTip) wrote:
Apple II's needed a simple hardware hack (a couple
of wires or simple
components) in order to make one of the hardware memory addresses
correspond to the state of the vertical blanking interval (it would either
go high or low when vertical blanking was going on). IIe's and IIc's had a
memory location (hex C013?) that does that for you, no hardware hack
required. (Although, $C013 behaved in the opposite manner than Lancaster's
hack did--perhaps $C013 went high when Lancaster's memory location went
low and vice versa, so Lancaster's programs had to be modified a slight
bit in order to work).
Ah. Thanks for clarifying that.
Well then this brings me back to wondering how those programs that allowed
mixed video modes on the Apple ][ worked. They required no hardware mods.
Hmmm.
In any event, once you had the vertical blanking
information, you could
write machine language programs that would switch between Apple graphic
modes just about anyplace on the screen (within limits). You were more or
less limited to static displays because of the timimg requirements, but
you could still do some interesting stuff. I typed in a few of the
programs, and still have them sitting around on a disk if anyone is
curious...
The programs I'm talking about I saw as demos on that Magazine Diskette
(Magazette) subscribtion service called SoftDisk (anyone remember that?
lots o' cool stuff on that). And they had hi-res animation mixed with
lo-res graphics and text-mode text. One day I will have to dig those
disks out and dissect the code to figure out how they did it. I don't
know why I didn't try to figure it out way back when.
There was one hi-res graphics game I was writing where I was going to try
to employ this trick and use a text line at the top of the screen to print
out the score. I knew it would involve having to keep excrutiating track
of each instruction cycle in the code to make the timing work. I never
completed this part.
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
5:41 p.m.
On Thu, 18 May 2000, Vintage Computer GAWD! wrote:
I have a bunch of Softdisk disks, mostly for the GS though (some will
work on earlier machines). I haven't really looked through them all
On Thu, 18 May 2000, Charles P. Hobbs (SoCalTip)
wrote:
Ah. Thanks for clarifying that.
Well then this brings me back to wondering how those programs that allowed
mixed video modes on the Apple ][ worked. They required no hardware mods.
Hmmm.
I wasn't aware that any such programs existed, especially for the II. Any
examples I should be on the lookout for?
In any event, once you had the vertical blanking
information, you could
write machine language programs that would switch between Apple graphic
modes just about anyplace on the screen (within limits). You were more or
less limited to static displays because of the timimg requirements, but
you could still do some interesting stuff. I typed in a few of the
programs, and still have them sitting around on a disk if anyone is
curious...
The programs I'm talking about I saw as demos on that Magazine Diskette
(Magazette) subscribtion service called SoftDisk (anyone remember that?
lots o' cool stuff on that). And they had hi-res animation mixed with
lo-res graphics and text-mode text. One day I will have to dig those
disks out and dissect the code to figure out how they did it. I don't
know why I didn't try to figure it out way back when.
7:13 p.m.
On Thu, 18 May 2000, Charles P. Hobbs (SoCalTip) wrote:
<...>
Well then this
brings me back to wondering how those programs that allowed
mixed video modes on the Apple ][ worked. They required no hardware mods.
Hmmm.
I wasn't aware that any such programs existed, especially for the II. Any
examples I should be on the lookout for?
I have a bunch of Softdisk disks, mostly for the GS though (some will
work on earlier machines). I haven't really looked through them all
You need to get issues from the '83-'86 range to find the demos I'm
talking about. SoftDisk had an advertising "section" on each issue and
there was one company that sold development tools to build programs with
mixed mode screens that advertised almost every issue.
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
8:41 p.m.
New subject: Softdisk and BEZ (was Cool AppleSoft BASIC trick)
Sellam wrote:
On Thu, 18 May 2000, Charles P. Hobbs (SoCalTip)
wrote:
<...>
As long as we're talking about SoftDisk, I may as well shamelessly hijack
the conversation. At least I changed the subject.
The one SoftDisk issue I owned (I'm not sure if I have it anymore) had a
demo for a game called Alien Encounter. This game was made by BEZ (who also
made things like Double Trouble, two arcade games side-by-side controlled by
the same joystick -- another one I no longer have) and featured a series of
puzzles.
I'm wondering if anyone else has ever heard of that game.
-- Derek
Well then
this brings me back to wondering how those programs that allowed
mixed video modes on the Apple ][ worked. They required no hardware mods.
Hmmm.
I wasn't aware that any such programs existed, especially for the II. Any
examples I should be on the lookout for?
I have a bunch of Softdisk disks, mostly for the GS though (some will
work on earlier machines). I haven't really looked through them all
You need to get issues from the '83-'86 range to find the demos I'm
talking about. SoftDisk had an advertising "section" on each issue and
there was one company that sold development tools to build programs with
mixed mode screens that advertised almost every issue.
8:02 p.m.
New subject: Softdisk and BEZ (was Cool AppleSoft BASIC trick)
On Thu, 18 May 2000, Derek Peschel wrote:
The one SoftDisk issue I owned (I'm not sure if I
have it anymore) had a
demo for a game called Alien Encounter. This game was made by BEZ (who also
made things like Double Trouble, two arcade games side-by-side controlled by
the same joystick -- another one I no longer have) and featured a series of
puzzles.
I'm wondering if anyone else has ever heard of that game.
The two sound (in the most vague sense) familiar. If you can remember
about when the issue came out I can check if I have it. I've got quite a
few SoftDisks through 1987.
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
3:31 p.m.
On 18 May 2000, Eric Smith wrote:
Sellam wrote:
Hmmm, I could've swore all the ]['s have it but I can't find the reference
to the location in the Apple ][ Reference Manual. And I've forgotten what
the address was. I don't think I have the //e Tech Ref handy so I can't
check that right away.
Hmm. Now I'll have to figure this out or else it'll continue to bother
me.
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
The Apple ][ has an address that you can monitor
that tells you when it's
in the vertical blanking interval.
Must be something they added for the //e, the ][ and ][+ certainly don't
have that.
3:58 p.m.
Eric Smith wrote:
Sellam wrote:
No they don't, but they do have a way to achieve a similar effect. (Sellam,
you might remember that we talked about this when I visted your house last
September.)
Because of the way the bus is constructed, you can read some address or
other and get the current byte that's being sent to the screen. By itself,
that won't give you the current screen location, but if you use a series of
marker bytes in a certain place (and make sure they ONLY appear in that
place), you can get the screen location. You may be able to store the
marker bytes in the "holes" in the screen memory map (that don't correspond
to any pixels).
This trick was described in the magazine _Computist_. There are one or two
"Best of Computist" books but they are out of print (I passed up the
opportunity to buy one). However, the magazines themselves have now been
scanned. Sorry, I don't have the URL.
Look for "Vapor-Lock". I think the name was created like this: Your
routine locks onto a certain part of the screen, but it uses fake, or
vaporous, information about how to do it. The fact that "Vapor-Lock" is
also a brand of plastic bag is merely coincidental. :)
-- Derek
The Apple ][ has an address that you can monitor
that tells you when it's
in the vertical blanking interval.
Must be something they added for the //e, the ][ and ][+ certainly don't
have that.
3:40 p.m.
On Thu, 18 May 2000, Derek Peschel wrote:
No they don't, but they do have a way to achieve a
similar effect. (Sellam,
you might remember that we talked about this when I visted your house last
September.)
Nope but go on... :)
Because of the way the bus is constructed, you can
read some address or
other and get the current byte that's being sent to the screen. By itself,
that won't give you the current screen location, but if you use a series of
marker bytes in a certain place (and make sure they ONLY appear in that
place), you can get the screen location. You may be able to store the
marker bytes in the "holes" in the screen memory map (that don't
correspond
to any pixels).
HMMMMM!
This trick was described in the magazine _Computist_.
There are one or two
"Best of Computist" books but they are out of print (I passed up the
opportunity to buy one). However, the magazines themselves have now been
scanned. Sorry, I don't have the URL.
My subscription start at around issue #27 or something. I tried buying an
entire run from #1 through like 40 or something from someone advertising
them on an apple2 newsgroup but he wanted way too much.
That was an awesome magazine! I learned so many cool hacks from it. I
also had a few things published in it.
I'll have to find the issue with that article and read up on it. Thanks
for the reference.
Look for "Vapor-Lock". I think the name was
created like this: Your
routine locks onto a certain part of the screen, but it uses fake, or
vaporous, information about how to do it. The fact that "Vapor-Lock" is
also a brand of plastic bag is merely coincidental. :)
It's also the name given to a condition your car can get on a hot day (oh
no, now all the gear heads are going to chime in with their explanations
of this).
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
1:11 p.m.
Most other-than-IO functions performed during I/O such
as graphics, sound,
etcetera on the Atari 8-bits utilized the fact that for 1 60th of a second
the screen is not painted. While the 'vertical blank' was occurring you
had several cpu cycles available. If you wrote very tight code you could
do a lot in those few cycles. On the Atari this was accomplished by GTIA
'display lists' which are programs for the GTIA coprocessor.
Apple interleaved graphics output (and DRAM refresh) with CPU cycles. This
works because the 6502 only performs memory accesses at very predictable
times. So there are no vertical (or horizontal) blank intervals in which
the CPU is not doing something else.
Can the Apple II be convinced to perform this feat? I
have allways
wondered but not passionatly enough to investigate about the Apple II
series i/o scheme.
In the case of disk and tape I/O, the Apple ][ is heavily dependent on
instruction timing. What it comes down to, is that no interrupts can be
allowed while a disk block read/write or any portion of a tape read/write
is happening. It also means that a multitasking OS can't block on I/O the
way a system that supported interupt driven port I/O or DMA could.
I assume that this was fixed somewhere in the Apple ][ line. Perhaps in
Unidisk type controllers?
Eric
12:44 p.m.
On Thu, 18 May 2000, Eric J. Korpela wrote:
In the case of disk and tape I/O, the Apple ][ is
heavily dependent on
instruction timing. What it comes down to, is that no interrupts can be
allowed while a disk block read/write or any portion of a tape read/write
is happening. It also means that a multitasking OS can't block on I/O the
way a system that supported interupt driven port I/O or DMA could.
I assume that this was fixed somewhere in the Apple ][ line. Perhaps in
Unidisk type controllers?
There was never really anything to "fix". You just don't interrupt the
Apple when it's reading or writing to disk. The regular IRQ signal is
turned off before a read or write with the SEI and CLI instructions. But
there's no way to disable the Non Maskable Interrupt, which some hardware
copy protection cracking aids gave you access to. Unless these cards did
something to specifically avoid interrupting during a disk write (I always
wanted one but never got around to getting one during their heyday) the
results would be unpredictable.
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
5:40 p.m.
::> Most other-than-IO functions performed during I/O such as graphics, sound,
::> etcetera on the Atari 8-bits utilized the fact that for 1 60th of a second
::> the screen is not painted. While the 'vertical blank' was occurring you
::> had several cpu cycles available. If you wrote very tight code you could
::> do a lot in those few cycles. On the Atari this was accomplished by GTIA
::> 'display lists' which are programs for the GTIA coprocessor.
::
::Apple interleaved graphics output (and DRAM refresh) with CPU cycles. This
::works because the 6502 only performs memory accesses at very predictable
::times. So there are no vertical (or horizontal) blank intervals in which
::the CPU is not doing something else.
I knew I liked the C64's setup better, even if I complain about VIC-II
DMA freezing the processor every eighth screen line.
--
----------------------------- personal page: http://www.armory.com/~spectre/ --
Cameron Kaiser * Point Loma Nazarene University * ckaiser(a)ptloma.edu
-- Klein bottle for immediate occupancy; inquire within. ----------------------
8825
days inactive
8827
days old
34 comments
19 participants
participants (19)
-
allisonp＠world.std.com -
ard＠p850ug1.demon.co.uk -
ckaiser＠oa.ptloma.edu -
cmcmanis＠mcmanis.com -
dlw＠trailingedge.com -
dpeschel＠eskimo.com -
eric＠brouhaha.com -
foo＠siconic.com -
jfoust＠threedee.com -
jimw＠agora.rdrop.com -
jlewczyk＠his.com -
korpela＠albert.ssl.berkeley.edu -
mikeford＠socal.rr.com -
pete＠dunnington.u-net.com -
richard＠idcomm.com -
rutledge＠cx47646-a.phnx1.az.home.com -
spc＠armigeron.com -
technoid＠cheta.net -
transit＠lerctr.org