wanted: dancin' demon .dsk
Zero dB
I presume it's abandonware, since I can't find anywhere to purchase
it.....
And, trs-80.com doesn't alow downloads anymore from what i can tell ??
So, I was wondering if someone could send me the dancing demon .dsk
file.
my email is jayson.anderson AT REMOVETHIS gmail
Thanks!
J
Zero dB
I need the actual .dsk so i can load into trs32
thanks!
J
Zero dB
Jayson
marmotking
By the way, you can get .BAS files onto an emulator. Look at XFER/
CMD.
George Phillips
resolution graphics (but still running on a TRS-80 Model 3).
http://members.shaw.ca/gp2000/dandem2.html
Also, Leo Christopherson has a web page with updated versions of
Android Nim and Snake Eggs.
http://www.leochristopherson.com/
-- George
Zero dB
Indeed, it is so much fun :D
Thank you for the xfer/ info!
Jayson
Zero dB
ah, neat! I am headed to check both out right now!
Thanks for sharing :)
Jayson
Mark McDougall
> You may be interested in my version of Dancing Demon with double-
> resolution graphics (but still running on a TRS-80 Model 3).
Your beam-hacking stuff is pretty cool - I've seen similar stuff done on the
Coco but I had no idea anyone had done that on the TRS-80 Model 3!
Regards,
--
| Mark McDougall | "Electrical Engineers do it
| <http://members.iinet.net.au/~msmcdoug> | with less resistance!"
George Phillips
> Your beam-hacking stuff is pretty cool - I've seen similar stuff done on the
> Coco but I had no idea anyone had done that on the TRS-80 Model 3!
Can you suggest a link to similar Coco programs? I'd love to see what
they're doing.
Mark McDougall
It's palette switching rather than character-switching...
<http://www.axess.com/twilight/sock/hicolor/hicolor.html>
Also, some more tricks...
<http://www.axess.com/twilight/sock/cocofile/demo.html>
David Librik
>You may be interested in my version of Dancing Demon with double-
>resolution graphics (but still running on a TRS-80 Model 3).
> http://members.shaw.ca/gp2000/dandem2.html
Wow. I've just read through your website and I'm happily astounded
to see that there are still people pushing the boundaries of what
you can do with a TRS-80.
I've recently finished reading "Racing The Beam"[*] about the
Atari 2600 programmer tricks used to write games on that
underpowered machine, but I never imagined the same techniques
could be used on the Model 3.
However, I have a couple of questions for you:
1. I see how on the Model 3 you can use the "video wait" option
to give you a horizontal synch position. But how exactly do
you get a vertical synch? How do you know when you've entered
the vertical blank period, so you can do game-related logic?
2. Bigger question, since I was a Model I programmer. How does
this work on that machine? You've got no "video wait" option,
so you'll have to count T states from some other kind of
synch point. Is this the vertical blanking interrupt? Again,
how do you determine that?
The Model I did have a real-time clock as an extra option
in the Expansion Interface, but I wouldn't expect that to
be synchronized with the video chain clock; I think it was
just an external clock that raised interrupts. Anyway, that
wouldn't work a basic 16K unit. So how do you get any sort
of video synch on a basic Model I?
You describe some of your sample programs as "it has a chance
on the Model I" (Dancing Demon) while others are "no way this
could be made to work" (Apple II BLOAD). What are you doing
differently that makes it insoluble?
I haven't tried downloading and converting the CAS files, but
I'd definitely like to see lots of source code. This is all
fascinating, and I'd like to drag out my M1 and get working.
- David Librik
lib...@panix.com
[*} _Racing The Beam_ by Ian Bogost and Nick Montfort, MIT Press,
published 2009. A brilliant synthesis of assembly-language
graphics hardware hacking and academic game design theory, and
probably the best study of retro-computing I've read. "Highly
recommended" (as they say).
George Phillips
> It's palette switching rather than character-switching...
> <http://www.axess.com/twilight/sock/hicolor/hicolor.html>
>
> Also, some more tricks...
> <http://www.axess.com/twilight/sock/cocofile/demo.html>
Good stuff. And what a small world -- I've worked with "Sock Master"
on a few game projects.
He laments that the CoCo demo scene never really took off. I don't
imagine the Model I/III demo scene is going to cach on fire either :-)
-- George
George Phillips
> I've recently finished reading "Racing The Beam"[*] about the
> Atari 2600 programmer tricks used to write games on that
> underpowered machine, but I never imagined the same techniques
> could be used on the Model 3.
Atari 2600 style programming was certainly part of my inspiration.
Never wrote anything for it myself but did some reverse engineering on
some Atari carts and helped port an Atari 2600 emulator to the PSP.
But what really started it was my brother and I pondering the extact
nature of the Model I's screen "hashing" and why the Model III did it
only a little bit.
> However, I have a couple of questions for you:
You'll find the answers if you read through the beamhacking posts but
I'm happy to save you the effort. For anybody who'd like to follow
along, start here:
http://members.shaw.ca/gp2000/beamhack1.html
> But how exactly do
> you get a vertical synch? How do you know when you've entered
> the vertical blank period, so you can do game-related logic?
The 30 Hz interrupt fires at the 192nd raster line. That gets you a
known vertical position which is refined to a known horizontal
position using the video wait (and accounting for the cycles used in
taking the interrupt and getting to one's own code). After that you
just count every Z-80 cycle executed to keep track of where the beam
is. After 128 cycles you're on the next line. And 33,792 down the
road the beam is back where you started. With the right tools keeping
track of cycles isn't as much of a problem as getting done in time. I
try to avoid conditional execution or balance both sides of an "if
else" to keep things simple.
> 2. Bigger question, since I was a Model I programmer. How does
> this work on that machine? You've got no "video wait" option,
> so you'll have to count T states from some other kind of
> synch point.
You're absolutely correct here. As far as I can tell the expansion
interface interrupt runs at 40 Hz and is driven by a different clock
crystal. I'm only about 5% hardware guy, but I don't think the
crystals would be accurate enough that you could even depend on the
interrupt being in some fixed relative phase with the CPU clock (which
would at least allow semi-automated synchronization).
The best idea I've had is punting to the user by displaying a test
pattern that they have to move around the screen until it lines up.
Rather like "Donkey King" (and others) on the Color Computer where it
made you press reset until the screen was blue instead of orange.
Manual sync is OK but there are a few discouraging factors. First,
it's tedious for the user and gives them every chance to break the
demo. Sorta like watching a bad magician who asks you to ignore
whenever you see through the trick. Second, it's tedious for
development (well, I can finesse that in the emulator were I so
inclined). Third, my sync screen isn't very good. Still, I'll make a
note to post it at some point. Finally, I've still got some things
I'd like to figure out on the Model III which is much more enticing.
Mind you, there's probably a one-wire hardware hack that would allow
syncing on the Model I. All I'd need is a jumper from some part of
the video timing chain to a port readable by the processor. Perhaps
even jamming the video output into the cassette port would work modulo
a resistor or something. But don't take my advice; I'm not kidding
about being a 5% hardware guy.
> You describe some of your sample programs as "it has a chance
> on the Model I" (Dancing Demon) while others are "no way this
> could be made to work" (Apple II BLOAD). What are you doing
> differently that makes it insoluble?
The video timing and blanking information, basically. See
http://members.shaw.ca/gp2000/beamhack4.html
http://members.shaw.ca/gp2000/beamhack5.html
With Dancing Demon having only 112 cycles per scan-line doesn't give
me much time to change the graphics. But I'm not right at the edge so
some tighter code (or skinnier graphics) might make it fit.
The Apple ][ bload runs code from screen RAM to blank out entire
scanlines on the Model III. A stock Model I only has 7 bit screen
memory which is a hinderance, but the real showstopper is that code
running from the Model I screen will not steal the display RAM from
the video hardware -- there will still be some characters that show
through. I guess you could mitigate the holes, but there's no way
you'd get a nice, solid black line.
> I haven't tried downloading and converting the CAS files, but
> I'd definitely like to see lots of source code.
I'm certainly willing to share the code. The sync code, cycle wasting
subroutine and cycle counting assembler are the core pieces and
they're already available. The demos themselves I'm holding off only
because there's always a bit of work to package up source and I like
to be absolutely certain they work on a Model III besides mine.
Perhaps I'm just getting too careful but I've been in too many "runs
on my machine fine" situations to suspend belief until at least the
demos have run on two machines.
Actually, I'm pretty confident the existing demos will be fine. But
I'd really like to get some more data on the weirdness I'm getting in
double-wide mode:
http://members.shaw.ca/gp2000/beamhack6.html
The bit where video writes in double-wide mode interfere with
instruction fetches make me think there's something subtlely wrong
with my Model III. Please drop me a line if you have a Model III and
would like to help.
-- George
N Morrison
Stan The Man
"Zero dB" <n...@email.com> wrote in message
news:59oda5ttni52fo7r8...@4ax.com...
I'd like to see someone update this to the 21st century. Fully 3D of
course....
dbgue...@gmail.com
please! - Many thanks!
George Phillips
> Can I please get a copy of this,
http://www.tim-mann.org/misosys.html
Or use this direct link:
http://www.tim-mann.org/trs80/Lance.zip
Bill Gunshannon
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>