h a l f b a k e r yCall Ambulance, Rebuild Kitchen.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
As you are probably aware, Im something of a retro
fan and also easily distracted. Consequently Im in the
process of working out how to use a Commodore 64 to
type documents and avoid distraction before
transferring them to a memory stick and posting them
on the web. Hence whereas this idea
may appear to be
decades out of date, it is in fact very much a current
issue for me.
One of the odd things about late-70s and early-80s
home micros was the huge mismatch between their
video and cassette interface bandwidths. For instance,
the ZX81 averaged about 250 baud on the cassette side
but was able to fling six kilobytes of pixels (albeit
character-mapped) at a TV screen twenty-five times a
second. Although this might at first suggest the use of
VHS cassettes to store data, this doesnt work because
VHS cassettes have rubbish bandwidth. Even so, this
means that the cheapest computer ever made was able
to achieve a bandwidth comparable to broadband back
in 1981. Of course its not much use nowadays and
unclear how this couldve been exploited. I still
steadfastly maintain, however, that this is an absurdly
uneven asymmetry present in all first generation home
computers.
I am currently confronted with the difficulty of getting
a Commodore 64 to communicate with laptops, tablets
and the like without further financial outlay. However,
there does seem to be a straightforward way round
this: use a QR-code style system.
Write a program which displays 2x2 pixel characters on
a 40x25 text screen with appropriate simple
compression algorithms. This is, due to caution, way
below the maximum limit on bandwidth. Proceed to
take screenshots with an ordinary digital camera,
perhaps part of another device. This would enable a
minimum of 750 bytes per screen to be transmitted,
allowing an uncompressed 64K address space to be
transmitted in eighty-seven frames. In fact rather less
than this would need to be transmitted since the video
RAM, firmware and whatever space is taken up by the
software in RAM are all out of action. Im primarily
talking about text as well, which can fairly easily be
compressed.
At this point you might imagine Im going to suggest
taking a video and allowing the whole 64K to come
across in less than two seconds. Im not, because this
is about a quick and dirty solution to the problem.
However, I am going to suggest borrowing an idea from
video compression and only recording the pixels which
change. The idea is that you do something like press
the spacebar to change the screen and take another
photo.
This could also, in fact, even have been done back in
the day with an instamatic camera, but the problem is
that without a scanner or some other optical device it
wouldve been difficult to get the information back
into the computer. There are various ways round this
though, such as printing the photo using magnetic ink,
and in fact even the camera couldve been bypassed by
just outputting the data on a thermal printer or
something.
https://developers.chirp.io/
https://developers....orials/command-line Chirp doesn't exist on a C64, but you might be able to borrow some ideas from their data-to-audio implementation. [zen_tom, Oct 20 2018]
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Destination URL.
E.g., https://www.coffee.com/
Description (displayed with the short name and URL.)
|
|
Thanks [Jutta] for sorting everything out by the way.
I really appreciate it. |
|
|
So much fun giving a bun.
Thanks Jutta and Inyuki!!!! |
|
|
What about using a modem, plugged into the expansion port ? |
|
|
C64 modems supported 600/600 duplex, or 1200/75 Prestel. Slow, but practical. Just use a cheap PABX and a PC modem as the intermediate. |
|
|
Then there's the cassette port. The output is TTL levels; link it to a PC printer port via an opto-coupler, then decode the data stream. |
|
|
IIRC, somebody made a tape backup program for the
Commodore Amiga that recorded onto a standard VHS video
tape by displaying the data on the "screen" (which was
expected to be connected to the input of the VCR). |
|
|
For the life of me I can't remember how you were supposed
to restore the data from these tapes. |
|
|
[Ian], there is a CBM-64 mouse, used on GEOS, and
also a light pen. |
|
|
You could encode the text into morse, then play that as a
stream - that way, depending on your recording medium,
you'd effectively have an open-ended amount of data-
transfer, limited only by the baud-rate, the capacity of
your recording medium, and the length of time required
to transmit your data. If you use ascii (petsci, but who's
counting), that's a 4-byte space, covering 127 characters.
The C64's SID chip's specs suggest it's able to cover 8
octaves, which gives you between 64 and 96 separate
frequencies (depending on whether you include semi-
tones) which *should* be plenty, if you slim down the
charset to alphabetic (upper and lower), numeric, and a
selection of punctuation characters. Let's say a set of 64.
Then, if you experiment, you might be able to play a
character note every 0.1 of a second, giving you
transmission speed of 10 characters a second. At that
rate, you'd be able to transmit War and Peace (which
contains 587,287 words, at an estimated 6 characters per
word) in about 98 hours. You might be able to trim that
down with a bit of tuning, and perhaps some special
bleeps for common dipthongs, common words etc. Even
more with some compression. Anyway, the point is, audio
may be the way to go. |
|
|
I just looked up Chirp, they claim to attain a speed of 32
bytes in 4.52s (56.6 bps). So that's War and Peace in 17.5
hours. or 0.057 W&Pph. (apparently people read at about
0.03 W&Pph, so it's still twice as fast than reading it out
loud into a dictaphone). |
|
| |