h a l f b a k e r yPoint of hors d'oevre
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,
|
|
|
Please log in.
Before you can vote, you need to register.
Please log in or create an account.
|
DVD players are now available enough to allow one to pick up some of the older ones for free, from bins, landfill, people giving them away or one might have some just lying around the place. Other things one might acquire in such a way are old microcomputers. Old computers, however, have cruddy graphics,
sound and processing power.
It seems to me that putting the two together would require a bit of jiggery-pokery but would still be feasible with sufficient understanding.
They can, at a minimum, read DVDs and CDs, navigate a file system, display high-quality sound and graphics and perform certain mathematical functions very fast on large data structures. An ancient eight-bit computer is usually not up to these tasks but has the advantage of being very hackable. I'm going to assume some kind of eight-bit computer's being used, with a full address space of RAM, probably running Forth on a Z80 (with a big RAMpack of course!). So in other words, probably a Jupiter Ace, for the sake of argument.
Take three DVD players, one of which is still usable as such. Use the one which still works fine as a storage device. This device is already way beyond anything which an eight-bit micro was normally connected to, with more than nine gigabytes of storage and quite an impressive loading speed. It can at least store data in CD audio form, giving it a transfer rate of over fifty Kb a second. In other words, it can load something the size of the entire address space in a second or so maximum. Probably the whole software library for that computer could be stored on a single disc. Also, something like Project Gutenberg or Wikipedia could be stored on it, both easily viewable via the micro on an old-fashioned telly. This is of course somewhat reminiscent of the Humane Reader and the Humane PC, and it can also be used as a sort of eBook reader, given appropriate discs.
Ironically, saving speed would still be very slow, maybe onto a solid state voice recorder.
Take the bit of the DVD player which reads the disc data and converts them to displayable form. This can do DCTs, meaning it can do trig functions and various other things, given the right data. It can in fact do a whole load of them in quick succession. So, present it with the data via an otir instruction and read it back in with inir, and you have a method of processing large arrays of data quickly. Some buffering may be needed, though i don't know about this. I'm sure this is useful and superior to what the Z80 can do on its own, at least in terms of speed.
Then, take the final DVD player and use it for output. Get the computer to transmit data as if from a DVD. This would give you true colour output at higher than VGA resolution with a text format well over your bog standard eighty column job, interfaceable to a fancy display way better than the old TV plugged into an aerial. It can also do CD-quality or better digital stereo sound.
An initial operating system CD is loaded via the cassette interface, with the usual tape format which tells the old computer what to do after you turn it on. That does the rest of the interfacing and you end up with a rather weirdly mismatched eight-bit micro which has under sixty-four Kb RAM but also high-resolution true colour graphics, fantastic sound, interesting processing abilities and a rather high bandwidth for loading but not saving. And it's even useful because it can store huge amounts of text at least, and manipulate audio, image or video files of sizes up to the RAM available.
Everything is interfaced to I/O ports via the computer's PCB, not via any serial or centronics interfaces it may have, which i presume would be too slow.
I would love to try building this but i know it's beyond me.
Humane PC and Humane Reader
http://www.linuxjou...computer-save-world
Second cousin to this [nineteenthly, Nov 11 2010]
Commodore 64 Web V2.1
http://120.146.162.194:8080/
Using a specially created ethernet adaptor, the FB-NET Cartridge, this web-site is hosted by an old 8-bit C64. With a similar setup, why bother with DVDs and instead use ethernet connections to connect to any computer/device that supports tcp/ip? That way, all you ever need to worry about is creating a tcp/ip layer in order to integrate other technology. [zen_tom, Nov 15 2010]
[link]
|
| |
Presumably the stuff is sufficiently smooshed together that the individual functional components can't be separated, but some things clearly can be done. Take a CD player for example. There are clearly going to be pairs of wires which power speakers. These pairs can be attached to a jack plug and an uncompressed audio recording of cassette data from a computer clearly could be loaded into an ancient computer that way. As regards the DVD player, there is going to be a series of ons and offs going down a wire at some point being turned into something else which will be sent down other wires. These can all be detected and produced. |
|
| |
I'm sure it's doable. Loading data from a CD at a relatively low bandwidth is, for a start. |
|
| |
// Again, this idea is more should than can // |
|
| |
I do realise this is entirely pointless but i also don't see having a point as much of a priority on the HB. And yes, i'd heard that too, about the rarer elements. |
|
| |
replacing the cassette player with a CD/DVD player should work quite well. |
|
| |
The dvd player already has more processing capacity than an 8bit computer and a far faster clock speed. the 8bit computer is also blessed with an anachronistic video card and would be completely overwhelmed by the task of producing even low frame rate hi-rez output. ditto for sound. The data rate on the motherboard would never be able to deliver fast enough to meet the clock speed of the DVD read head, nor would it be able to respond to commands from the read positioner. It would be far easier to kludge new firmware into the dvd player directly. I imagine that an infrared keyboard isn't out of the question, and expanding/stacking the on-board memory should be do-able. But then you just have a hopped up DVD player and you need custom DVDs and software and ETC ETC ETC. |
|
| |
Yep, i realise all that! Even so, i think there are ways round it. |
|
| |
I think the computer is more blessed with no video card at all most of the time. Instead, it'd do it by discrete logic or something like a 6845 or 6847, or do almost all of it in software depending on the model. However, that's not important because what the computer is doing is pretending to be a video DVD to the third DVD player. I also envisage something like a buffer and a shift register between the two. The video data are already very compressed. Those very compressed data wouldn't need so big a bandwidth. As it stands, an eight-bit micro interfaced to a TV can already manage something like a million baud. |
|
| |
In a way this is a re-hash of a thought i had about thirty years ago about using a teletext decoder as a computer display. |
|
| |
It's all very well having a DVD player but you can't do your accounts on it or write letters. |
|
| |
[bigsleep] - on your first anno, the same thing seems
to have happened with cars. |
|
| |
It seems to be partly the result of regulations and scale. In any case, one thing which definitely could be done would be to interface a CD player to an eight-bit computer and use it for data storage, which would make it an eBook reader at least. |
|
| |
what exactly is the x86 processor doing to the data on the DVD player, remembering that the DVD player is inclined to read data at a fixed rate, progressively and has a very very slow fetch speed. You can't exactly expect the operating system to be on the DVD. You also cannot expect for an anachronistic processor to "feed" data into a dvd player at the rates required to simulate a DVD head. These are simply impossible requests. |
|
| |
It's not an x86 CPU, it's something like a Z80, 6502 or a 6809. Is there a reason why a buffer consisting of semiconductor memory couldn't deal with this? |
|
| |
DVD players transfer data at under two megabytes a second. A Z80A runs at a clock speed of four MHz. Is there something i'm missing? |
|
| |
If i burn a disc with the O/S in audio form at least, there will indeed be a disc with the operating system on it. Wait states happen - don't consider that a problem because eight bit CPUs generally did sit around doing that for a while. Once you've loaded the O/S, you can simply eject the CD it's on and replace it with another disc. There is stuff between the processor and the DVD hardware. |
|
| |
I may well be missing something important about your objections, but it's true that i am missing them because none of what you say seems insurmountable to me. |
|
| |
Codec compressed DVD video pipes at data rates of 3.5 to 6 Mbps. Lets say you drop your OS into a DVD and compress it into a chip compatible format, then kludge the drive sector calls into a format that the dvd player can handle, track time position etc. (essentially a ROM drive right?). Now you have a very large, but ROM, disk operating system, BUT with a sector to sector tracking time that could compete with a tape drive because the head on a DVD player moves very slowly (in most if not all cases). Now the OS is making sector calls to the disk and waiting for the read at a 2mbs pipespeed (much slower than dvd quality video, CD quality audio maybe). Now your motherboard has a video output usually capable of 600/800 tandy graph or cga which consumes the entire capacity of the graphical pipeline on the motherboard. The serial bus or the card slots might be able to run faster but the output for DVD video is in no way coming out of the video side, you need a card and a whole new kludge. The output kludge requires the computer to compile and compress a codec stream that satisfies the chip on the second dvd player. For menus this should be well in order, but for other output, especially any output that isn't coming directly from the read head on the drive player (which imho we had to de-clock massively) that is going to be an insurmountable challenge, even if the second dvd player is similarly de-clocked. If the second player is de-clocked then it will no longer produce a stable signal to the TV which will in turn flicker and fail to hold the signal. It seems like a lot of work to go to, especially when i routinely see Imacs with superdrives in the trash, usually lying under discarded DVD players. |
|
| |
Why are you talking about sixteen bit computers? They're a lot more advanced than what i'm suggesting. CGA is a standard for IBM PC clones, nothing to do with these computers. CGA was perceived to be pretty rubbish at the time, as i recall. Also, none of the codec stuff is being done by the eight bit computer. That's one reason why the DVD players are there. It absolutely is a lot of work to go to, but the fact that something is pointless isn't a consideration for me. |
|
| |
Surely the speed at which the graphics is provided is slower? Because the video and audio are both compressed, the rate at which they go into the attachment for the photocell or whatever detector is used has to be slower. It's not like the whole megabyte and a half has to be transferred by the CPU itself in a fiftieth of a second. The DVD player will be generating an image as if it is itself a graphics card, but the transfer of the data is a lot slower into the display portion of the player. It has to alter maybe two hundred bytes at a time if it's sending a character to the display. Why is it not just a small frame, maybe an entirely blank screen, followed by something like a maximum of around two hundred bytes in twenty milliseconds or so representing the difference between that blank screen plus one character, and so forth? |
|
| |
The DVD player must receive all data in a supported codec (compressed file format) This information is translated into the expected final format (audio channels, rasterized video stream) and thus must come at a rate that will fool the DVD player into thinking that it is producing a full output (a black screen and silent audio at a minimum) The data comes from the disk at a speed fixed by the drive speed of the motor with minimum and maximum values. Getting the DVD player to act as a ROM drive requires you to hold to a retrieval rate of rasterized video and DVD tracking. Slower than a floppy but faster than a tape drive. |
|
| |
On the other hand I do not believe that you could persuade it to act as a graphics card and thus become the outfeed, even if there was a card specifically for this purpose, which there isn't the pipeline rate to the DVD player could not be generated. |
|
| |
It's possible to have a DVD with completely uncompressed digital audio, so it's at least possible to load data into a computer that way, even if the best that can be done is for it to carry audio recordings of computer cassette data. Even then it could carry three megabytes of data which would be accessible just as a cassette recorder's data would be. The chances are the band width and capacity could be a lot higher than that. CD players became available at a time when most consumer digital electronics were eight bit and are of a comparable level of technology, so i really don't see a reason why at least that can't be done. Therefore, even if none of the rest of this idea is doable, eBooks in plain text are. Uncompressed PCM has been around for more than seventy years and is a form of data accepted by DVD players. |
|
| |
I think the least feasible part of the idea is using a DVD decoder to do mathematical functions. |
|
| |
Finally, the display issue. I don't know if it's part of the standard or not but i've never knowingly used a DVD player which doesn't display JPEGs, even the very cheapest a decade ago. A black square at eighty-five percent quality and DVD PAL resolution has a size of less than three K. A black JPEG of the same resolution with the alphabet in eighteen pixel high characters is about twice that size. These are not enormous amounts of data. |
|
| |
Two words: "Selective Update". |
|
| |
Most of a JPEG will be the same when a character is added anywhere on it. If i'm reduced to using JPEGs, various things are still possible, though more like Quantel or that old analogue TV manipulation than conventional graphical displays nowadays. Selective updates would allow the image to be changed faster, i think. If not, i maintain that interesting demos would still be possible by interfacing an old computer to a DVD player as a display. |
|
| |
Well that's another matter entirely, but also quite subjective. |
|
| |
how is your Atari going to produce a data stream that simulates a DVD drive, even at the lowest supported DVD read rate (1X CD). Its a lot of data to be feeding. A lot more data, even Uncompressed (JPG requires substantial compression from a raw format). What kind of frame rate could you expect if you could surmount the bandwidth issue? This is a computer that struggles to produce a monochrome output, how will it be able to produce frame after frame (even with very low content) of a compressed image format? |
|
| |
I wouldn't say it struggles exactly. I chose a Jupiter Ace as an example. There are plenty of more colourful examples, such as the Apple II, BBC Micro, MSX standard micros and the Ataris. However, this isn't all there is. I have shifted my position on this somewhat. Whereas i still believe that some text display is possible and to a limited extent pixel addressable graphics, other interesting things can be done, i think - need to look this up though and do a bit of experimenting. There clearly are small files displayable as JPEGs, though only something pre-prepared is likely to be photorealistic. I'm going to try something with this because i'm pretty sure this can be done. |
|
| |
So you're suggesting getting three broken DVD players (and some unspecified custom interconnection hardware and software) and spending a lot of time and money to make them work together as a
not-very-good computer, which will be flakey and probably be unable to run anything? |
|
| |
A possible addition to the mix - you know those clever fake-cassettes that you can plug a usb, or flash-memory card into that, when placed into a cassette player, will respond to the motion generated by the wheel-motors and fast-forward, rewind, and most importantly, play, analogue, real audio noises from a library of mp3 recordings? Why not use one of those as your data input/output interface? You can use the crappy computer's existing i/o via the cassette buffer and record/load from the big storage of the DVD. You might have to wait for a bit for the stuff to down/upload - but presumably there's clever ways to increase that speed with clever encoding. |
|
| |
You do have a limit on what you can emulate graphically - so while you wouldn't have to utilise the old computer's graphics output, you'd be ignoring the 20% of the computer that was devoted to that task, instead using resources on an already strained CPU to do lots of encoding, which, at 30-year-old technology standards, is going to be a bit tricky. |
|
| |
Sure, you could put a newer computer in the middle to provide a sort of protocol/translation layer to help speed up the process, but you could probably have just started out with that part in the first place and not had to bother with all the 8-bit/DVD gubbins. |
|
| |
There was a lot of work done in providing alternative i/o options to 8-bit computers about 10/20 years ago, such as Star Commander which allowed you to plug (once you'd built the plug) your C64 disk drive into an IBM PC and transfer data from 5-1/4" floppies onto your hard-drive - and then (I think) go the other way and have your hard-drive emulate a 1571/1541 disk-drive. |
|
| |
So there's precedent on the storage element here - but on the display, it's possible, but only in the same way that it's probably also possible to build a steam-controlled tcp/ip stack controller, assuming you can get your hands on the parts. |
|
| |
Going to churn this because i had an extra idea on this matter: |
|
| |
This is a perverse method of storing data in video files which probably seems absurd but makes sense in this application. |
|
| |
An MPEG video consisting of a series of keyframes and no other information, alternating black and images. The images consist of a grid of eight pixel wide squares each with one of eight colours, representing maximum and minimum RGB colours. This enables about two and a half kilobytes of information to be stored and read easily per two frames. |
|
| |
When the video is played, it will transmit a sync pulse which can be detected by an appropriately interfaced computer, for example even via an RF socket. The computer will then receive a signal representing the first scan line consisting of the first line of ninety squares, each of which repeats the same three bits several times. The whole sequence is then repeated eight times. This works as error-checking - a checksum can be calculated at the end of each line and compared to its successors. Eight pixels allows the compression to be optimised (i think, depends on if JPEG and MPEG images are compressed in the same way). The computer then looks out for signals at the black level, which probably wouldn't be transmitted at anything like fifty fps because the video is not going to be as well-compressed as normal video would be. However, the maximum bandwidth for this format would be fifty-odd kilobaud. The efficiency is very low of course, but is still better than an eight-bit mono MP3 of a tape file. It also allows images to be stored on a DVD and processed by an ancient computer. |
|
| |
You can already store text and images on a DVD and play them back with an ordinary television using the firmware of the DVD player. The capacity is built in. |
|
| |