| |
yago
Registered: May 2002 Posts: 333 |
Demos which load from tape ?
After reading covert bitops rants about irq-tapeloader, i wondered if there are any Demos which load their next Part from Tape ?
Something like a castro ?
|
|
| |
iopop
Registered: Dec 2001 Posts: 317 |
Not what I heard of.. However, a demo on vinyl would be even nicer.. |
| |
SIDWAVE Account closed
Registered: Apr 2002 Posts: 2238 |
Hmm I never saw that, even in 1985, but I recorded some programs that they sent out on the radio as turbotape.
Mostly garbage, like home economy planner and video tape database programs etc. No games/demos.
|
| |
yago
Registered: May 2002 Posts: 333 |
Maybe compo-rules for c64 should not only allow a c64,1541,yc-cable, but also a c64,1531,rf, so that "lowfi" demos must not be held in wild competetion..
|
| |
Cybernator
Registered: Jun 2002 Posts: 154 |
The idea is to be able to load the next part while the previous is still working. But with tapeloaders, that's pretty much impossible (except with some very simple animations, but that's not the point). |
| |
cmp Account closed
Registered: Jun 2002 Posts: 4 |
I guess people would have a tendency to scratch their files if they were on vinyl... |
| |
TDJ
Registered: Dec 2001 Posts: 1879 |
Quote: I guess people would have a tendency to scratch their files if they were on vinyl...
Very funny :) |
| |
yago
Registered: May 2002 Posts: 333 |
Quote: The idea is to be able to load the next part while the previous is still working. But with tapeloaders, that's pretty much impossible (except with some very simple animations, but that's not the point).
Impossible ? I'll do it ;-)
If I understood your Article, while irq-loading from tape, there has to be always the same Amount of cycles for the "background stuff".
That would require some thoughts, but it should be possible to have effects running while irq-loading.
Whats a sane limit for the amount of rastertime while loading ?
However, last Time I programmed the 1531 is more then 15 Years ago, and even that was simple basic-turboload-interaction..
Another possibility is to connect the datasette-output to the sid-input, that should give some decent samples..
|
| |
Cybernator
Registered: Jun 2002 Posts: 154 |
> Impossible ?
Read again, depends on what you are doing. Effects which require
precise timing are impossible, and even Crossbow will have to humbly
agree. :) (ok, they are possible if hellish flickering is allowed :))
> I'll do it ;-)
I'll have to admit, it's always nice to see something never
done before. :)
> If I understood your Article, while irq-loading from
> tape, there has to be always the same Amount of cycles
> for the "background stuff".
I assume "background stuff" = the effects. Well, no actually.
'The same amount of cycles' thingy was in the saver. Since you
are not using a timer when saving, you have to be careful about
how many cycles have passed, and record the pulse at the correct
moment. It would've been simple if there weren't for the different
branches.
> That would require some thoughts, but it should be
> possible to have effects running while irq-loading.
> Whats a sane limit for the amount of rastertime while
> loading ?
Let's clear some things first. With diskloaders, all the effects
go into an IRQ, so they have higher priority over the loader.
In fact, the loader has the lowest priority since the protocol
is completely asynchronous (thank the 1541's CPU :))
With tapeloaders, it's vice-versa. The loader goes into an IRQ, giving
it the highest priority, which is pretty logical. With diskloaders,
the 1541 takes care of all timing-critical parts (the low-level
disk surface access). But since the tape lacks a CPU, the 6510 has
to take over and do all the timing critical parts. So loading goes into an
IRQ.. Now guess what would happen if you do VSP. No, simply guess
what would happen if you want to display some rasterbars.
Should you somehow make the rasterbars have higher priority than
the loader, you'll always end up with ?LOAD ERROR. Ah, those were
the times. :)
So back to your question, there's no need to worry about a rastertime
limit. :)
There's a possibility that you make the short pulse at least one frame
long, and the long one about two frames long, so you can have the effects in IRQ
and loading outside the IRQ (you only have to make sure that the loader will NEVER
miss a pulse). But one probably couldn't express the slowness of such a record, so
that has no practical purposes.
> However, last Time I programmed the 1531 is more then
> 15 Years ago, and even that was simple basic-turboload-interaction..
That's the hardest part, getting to work with it. After you make your
first Turbo250 clone, IRQ loading should be a breeze. :)
> Another possibility is to connect the datasette-output
> to the sid-input, that should give some decent samples..
Yeah, 1-bit samples. :) Perhaps you've tried Digitizer Datassette?
Oh, almost forgot: tape loading is hellish slow. A Turbo250 record
(which is much faster than IRQ-loader record - don't ask me how much, though :)),
is as fast (or should I say as slow) as a 1541 with the original kernel routines.
Hopefully I haven't destroyed your enthusiasm.
NO! Don't throw your Datassette! :P At least the tape has higher capacity than the
disk, making it a perfect backup storage. I wonder how many disks would I need
to transfer the games from my ca. 200 tapes. :) |
| |
yago
Registered: May 2002 Posts: 333 |
Thanks for the clarification concerning disk/tape loading.
Hmm.. no raster effects.. :-(
You misunderstood my datasette-sid idea.
The datasette must be modified, so that it has a headphone-connector. With this, one can not only control the loading, but also put audio-cassettes into, and listen to music.
And this output shall not be digitized, just given to audio-in, so that the sid can filter it.
Surely this is cheating, because hardware-mods are required!
PS: I dont throw datasettes, just Disks and Printers!
|
| |
Hoogo
Registered: Jun 2002 Posts: 105 |
You surely can load from tape while having rasters or things like that. Pulses from the tape are shown in the Irq-Register $dc0d.
-Usual Turbotapes loop and watch $dc0d. The number of loops needed tells about the lenght of the pulse on tape.
-Allowing these Irq's is neat. Then you don't count in a loop, then you read the timers.
-But you can also check the register regulary, i.e. every 63 or 126 cycles, and put that into the raster-routine.
And the speed of the tape-loaders is limited by the quality of the tapes. When connecting a PC-Soundcard or anything else to the usual port, you can have much faster loaders. But I think that would be called cheating :-)
|
| |
algorithm
Registered: May 2002 Posts: 705 |
As a past C64 Coder without a floppy drive. my last multipart demo's consisted of a tape irq loader which would display a part while loading the next. The main restriction was lack of solid raster timing, altough music, split screen etc was possible (I think sprites on screen caused load errors?)
|
| |
Graham Account closed
Registered: Dec 2002 Posts: 990 |
@Hoogo:
actually it's vice versa. samples are not very suitable for a storage which is based on variable signal lengths. this is way more accurate on an analogue tape than on a 44100 or even 22050 Hz sample... think of it: 44100 Hz = 22 cycles resolution. that's why very tight loaders do not work when converting them from TAP files to real tapes via audio out. |
| |
Oswald
Registered: Apr 2002 Posts: 5094 |
for the "loading is not possible beside raster effects" problem, I got an idea:
why not save the files in an insane format ? so when the raster effect is displayed, no bits come off the tape ? :) then for the rest of the screen they can come as they used to :). |
| |
Hoogo
Registered: Jun 2002 Posts: 105 |
@Graham:
But also tapes can only store a maximum frequency, afaik they drop at about 20 kHz. Though a human might not hear that, the digitized picture should change a lot. And something I'm very unsure about: I think that tapes store their data after modulation with a 20 kHz-Signal, just like AM-radio. At least these theories explained to me why I didn't get my turbotapes work some years ago. 4*22 cycles were very unstable, though the save-routine was nearly as accurate as a raster-routine. Now with PC-generated wavs 2*22 cycles work fine.
|
| |
Hoogo
Registered: Jun 2002 Posts: 105 |
@Oswald:
I can't imagine a way how to sync tape and screen. I don't believe that turning the motor on/off will do... |
| |
Oswald
Registered: Apr 2002 Posts: 5094 |
hoogo: it depends on how accurately (in terms of timing) can the tape replay the recorded data. I did not mean to turn the motor on/off, just simply dont store data on the tape when the raster effect takes over. so there would be empty gaps on the tape, in synchron with the occurance and length of the raster effect per frame. |
| |
Hoogo
Registered: Jun 2002 Posts: 105 |
Oswald: But when playing the demo you have to press play when the vic starts a frame. Otherwise you need a routine to sync the vic with the data from tape, only way I can imagine is by stopping/starting the motor. An dthe motor has to run very accurate for a long time, and I don't believe that it is. |
| |
algorithm
Registered: May 2002 Posts: 705 |
Give maximum priority to the tape loader and resort to using flickering rastersplits (hide it by empty gfx etc) |
| |
trident
Registered: May 2002 Posts: 91 |
You could also store every bit X times (for some good value of X), then synchronization would not have to be as perfect. Lets say that you choose X so that every bit is equivalent to 8 raster lines, then you would only need to sample the tape input once every 8 lines and it would not matter exactly when the sample took place.
I don't know how fast it would be and I know too little about tape loaders to know exactly how the bits would have to be encoded as pulses for this to work. |
| |
Hoogo
Registered: Jun 2002 Posts: 105 |
Unfortunately the sampling is not done by the hardware, tape-loaders have to work even below that level. The irq-register that is used for the tape is not like the usual IO-Ports. It doesn't tell WHAT happend, it only tells IF something happened since your last check, and its left to your loader to decide if something happens fast, slow or whatever you invented. So if you write 8 Samples to tape and ignore 7 of them, the answer of the register will always be "yes, something happened" |
| |
trident
Registered: May 2002 Posts: 91 |
Ok, so then we can use the "yes something happened" signal to encode a "1" and absence of the signal to encode a "0" :-) |
| |
Oswald
Registered: Apr 2002 Posts: 5094 |
tapeloading sux |
| |
carlsson
Registered: Nov 2002 Posts: 41 |
Since yago already is considering modifying the Datassette with a headphone jack, why not rebuild it completely with a small CPU and data buffer, so the timing-critical work takes place inside the tape recorder? :-) If you also add a software controlable fast forward and reverse mechanism, it soon becomes an "intelligent" serial random access tape device (did someone say Microdrive?)... |
| |
yago
Registered: May 2002 Posts: 333 |
Quote: Since yago already is considering modifying the Datassette with a headphone jack, why not rebuild it completely with a small CPU and data buffer, so the timing-critical work takes place inside the tape recorder? :-) If you also add a software controlable fast forward and reverse mechanism, it soon becomes an "intelligent" serial random access tape device (did someone say Microdrive?)...
A datasette plus cpu modification is beyond my "cheating with hardware" abilities. If one really want to do this, the "clever" datasette should have an IEC-Port.
The modification I describe is already done by some people plus there are these cassport-to-hifi[1] adapters. And my hifi does have a headphone :-)
@Oswald: Tape loading does not only suck, it sucks slowly!
[1] In the golden Eighties, as I did not have enough Money for a Datasette, there were adapters to connect your normal audio-cassette-player to the c64. |
| |
Clarence
Registered: Mar 2004 Posts: 121 |
Check 'We Can by Vision' 2nd part, for a tape-interactive demopart. |
| |
Rattus Account closed
Registered: Apr 2004 Posts: 34 |
This is kinda off-the-topic, but does anyone remember a device attached to a C64's port... maybe cassette port ?...
that made it able to load from CD-player with cassette load commands ? The CD was propably some custom format CD for the cassette/cd-module... In finnish magazine Mikrobitti was a review of such thing... It would be nice to know what the hardware had eaten... :)
|
| |
Hoogo
Registered: Jun 2002 Posts: 105 |
Such an CD-Player-Adapter was once produced by Rainbow-Arts. They sold a CD with some games by them. Pentagon (a german scener) produced about 15 pieces of such adapters. I'm currently involved into a kind of upgrade to these. |
| |
uzzy/entropy Account closed
Registered: Nov 2005 Posts: 4 |
Don't know about a castro, but we did once have a demo on the front of Commodore Format. (Is a castro like a dwarf castrato? (-; ) |
| |
enthusi
Registered: May 2004 Posts: 677 |
Heh,
I just hit this old thread by accident.
Well, here we go:
A Load of TAP |
| |
goto80
Registered: Jan 2002 Posts: 138 |
also Deep Throat by DUREX
Deep Throat |
| |
Zer0-X Account closed
Registered: Aug 2008 Posts: 78 |
While we're at it...
http://oms.wmhost.com/Rainbow_Arts/ |
| |
Klegg
Registered: Feb 2006 Posts: 16 |
Goto80:
Was just gonna post that link as well, hehe. |