Question about IDE interfaces
zxbruno
like to use them (the DivIDE+, for example) to read/write large data
files. If I want to load a full-screen video, for example, I know I
can load a .tap or .tzx with thousands of screen files, but that's not
what I'm looking for. Why should we have thousands of 6K screen
files, when we can have just one file? I would like to be able to have
a player that would read data from the cf card (or any other media)
and play it, while using the Speccy's available ram as a buffer. This
could be used for full-motion video and audio playback too. Any ideas
on how to do this?
Thanks.
spi...@freenet.co.uk
does open#/input#/print#/close# work with the ide interfaces?
--
| |What to do if you find yourself stuck in a crack|
| spi...@freenet.co.uk |in the ground beneath a giant boulder, which you|
| |can't move, with no hope of rescue. |
|Andrew Halliwell BSc(hons)|Consider how lucky you are that life has been |
| in |good to you so far... |
| Computer Science | -The BOOK, Hitch-hiker's guide to the galaxy.|
zxbruno
>
> does open#/input#/print#/close# work with the ide interfaces?
I know that you can read the DivIDE's I/O port, but I'm not sure about
those commands.
Here's something made by Gasman that, if disassembled, could give an
idea of how to read video and audio from a cf card connected to the
DivIDE:
ftp://ftp.untergrund.net/users/gasman/zx/divip_let_forever_be.zip
(iso image,12.9Mb, to be run under Demfir)
And I quote Gasman:
"I can't guarantee it'll work straight off - success seemed to vary
from one machine to another (and possibly even one CF card to
another), and I never did get to the bottom of that. (It's all rather
timing-critical and error checking was one of the first things I took
out, so maybe I shouldn't be surprised)
Unfortunately I only seem to have a few scraps of the source code /
notes / tools I used to create it, but from what I remember the code
isn't particularly clever (just reading bytes from the DivIDE's I/O
port and outputting them to the screen or a 256-byte sound buffer, and
stopping periodically to dump something from that buffer to the AY)
and there's only 100-odd bytes of it, so it shouldn't be too hard for
an interested person to disassemble it."
Guesser
> zxbruno <zxspec...@gmail.com> did eloquently scribble:
>> Instead of using the new IDE interfaces to load snapshots, I would
>> like to use them (the DivIDE+, for example) to read/write large data
>> files. If I want to load a full-screen video, for example, I know I
>> can load a .tap or .tzx with thousands of screen files, but that's not
>> what I'm looking for. Why should we have thousands of 6K screen
>> files, when we can have just one file? I would like to be able to have
>> a player that would read data from the cf card (or any other media)
>> and play it, while using the Speccy's available ram as a buffer. This
>> could be used for full-motion video and audio playback too. Any ideas
>> on how to do this?
>
> does open#/input#/print#/close# work with the ide interfaces?
correctly
--
link my boring website http://alistairsserver.no-ip.org/
Matthew Westcott
[reading large files from IDE]
> does open#/input#/print#/close# work with the ide interfaces?
As far as I know, the only firmware that supports them (aside from ones
which just emulate older disk interfaces working with standard-sized
disk images) is the +3e, which has a 16Mb partition limit (and is only
usable on the +3/+2a).
What we're really missing at the moment is a firmware which:
a) works with FAT filesystems (or something else ubiquitous and
writable), and
b) presents that filesystem to the Spectrum operating system (as opposed
to hiding it behind an abstraction layer that only loads emulator files,
for example).
It looks like the long-awaited ESXDOS will fit the bill when it
arrives... here's hoping it supports streaming files.
(If you're wondering, my Let Forever Be video routine (and the earlier
soundless ones done by other people) ran under Demfir, and from what I
remember, relied on the assumption that the video data existed on the
disk sectors immediately following the player TAP file. This was a
fairly safe assumption on Demfir, where you had to 'bake' your files
into a static ISO image, but it won't cut it these days, now that
everyone's on FATware and expects to be able to just drag and drop files
at will...)
zxbruno
> What we're really missing at the moment is a firmware which:
> a) works with FAT filesystems (or something else ubiquitous and
> writable), and
> b) presents that filesystem to the Spectrum operating system (as opposed
> to hiding it behind an abstraction layer that only loads emulator files,
> for example).
>
> It looks like the long-awaited ESXDOS will fit the bill when it
> arrives... here's hoping it supports streaming files.
I'll send him a p.m. and give the suggestion. :)
Btw... Mike, the developer of EightyOne, is working on something for
the ZX81, but I see no reason why it couldn't be adapted for the
Spectrum..
Here's some quotes:
"What I'm working on is a standard DOS with installable drivers for
any mass storage device which just happens to use FAT32 as its
filesystem, making transfer of files between '81 an PC extremely
easy."
" OK, What I've implemented upto now:
A Command line interpreter, rather similar to command.com
Mounting upto 8 partitions (4 partitions on 2 drives - Max 8Gb per
drive).
Selecting the current active drive (A:, B:, C: etc)
Manipulating the current working directory (CD <dirname>, CD .., CD /)
Renaming Files and Directories (RENAME <from> <to>)
Deleting files and directories (DELETE <name>) though it doesn't check
the ensure a directory is empty before deleting.
Getting a directory listing of the current directory (DIR).
Running commands off disk. Commands are stored as .P files, so typing
"fred" at the command line will look in the current directory for
"fred.p" and if it exists, run it. I plan on being able to pass
arguments to commands to, by storing anything entered after the
command in a string before executing the program.
So, if I wanted a quick game of Manic Miner, the code can handle stuff
like this already:
C:
CD GAMES
DIR
MANIC
next on the list is file creation, saving programs etc.
I hoping to fit everything except the command line interpreter into an
8K block of relocatable code. The CLI itself will just be another
command that's loaded from disk when needed."
"if you want to take a look at where I'm at, I've put a new build of
EightyOne that supports IDE along with my FAT32 code here:
http://www.chuntey.com/eightyone/EOFAT32.zip
Full source code is included, for what it's worth...
Mike"
Direct link to the topic (If you're registered):
http://www.ts1000.us/cgi-bin/yabb/YaBB.pl?board=PROJIDEA;action=display;num=1188432079
zxbruno
directly to FAT32. No snapshots, no layers. Direct access to FAT32. :)
I tested your hdf image on Spin and got sound but the image was just
random pixels and attributes. I wonder if I didn't did it the right
way. I extracted the .iso, configured Spin to use Demfir, mounted
the .iso as hd1 and loaded the .tap file.
Andrew Owen
+3e code, and it now supports FAT if I remember correctly. Garry?
zxbruno
Remember three years ago when you tried to do a mod player for the
Spectrum, but a better routine couldn't be achieved without
sacrificing memory? Well, if we consider the external media as virtual
memory (or the +3E's abilities), maybe you could resume your work on
this.
Matthew Westcott
> I tested your hdf image on Spin and got sound but the image was just
> random pixels and attributes. I wonder if I didn't did it the right
> way. I extracted the .iso, configured Spin to use Demfir, mounted
> the .iso as hd1 and loaded the .tap file.
For the benefit of people who aren't reading the corresponding thread on
WOS... I've fixed up the Let Forever Be and Passion videos to play
correctly on Fuse with Demfir d0.5b (and hopefully Spin too, assuming
the symptoms above were the same ones I experienced with Fuse)...
let_forever_be: (choose your preferred format out of HDF and ISO)
ftp://ftp.untergrund.net/users/gasman/zx/divip_let_forever_be.fixed.hdf.zip
ftp://ftp.untergrund.net/users/gasman/zx/divip_let_forever_be.fixed.iso.zip
passion: (ditto)
ftp://ftp.untergrund.net/users/gasman/zx/divip_passion.hdf.zip
ftp://ftp.untergrund.net/users/gasman/zx/divip_passion.iso.zip
Previously, the player code started by advancing the disk position by
one sector, and consequently the stuff it was copying to the screen was
out by 512 bytes. Once I took out the 'add one sector' code, it worked
fine. Presumably an earlier version of Demfir handled the current-sector
pointer differently, and needed that adjustment. This is why we need a
firmware that lets user programs open raw files on the FAT filesystem,
so that the user program doesn't have to make a not-so-educated guess
about where its data is...
Matthew Westcott
>
> Remember three years ago when you tried to do a mod player for the
> Spectrum, but a better routine couldn't be achieved without
> sacrificing memory? Well, if we consider the external media as virtual
> memory (or the +3E's abilities), maybe you could resume your work on
> this.
Ooh, now that's a challenge and a half :-)
Some day I'd like to have a go at *something* that uses IDE media as
virtual memory - every now and then I start idly dreaming about a
multitasking OS with pluggable support for different filesystems, file
handlers, GUI elements... each existing as a relocatable blob of code
somewhere in virtual memory.
A MOD player using virtual memory doesn't seem too realistic though -
the nature of IDE devices is that you're reading things into memory in
512-byte chunks, and with a MOD player you could be accessing any bit of
sample data at any given moment - the overhead of loading in new
512-byte chunks would just be too great, and you can't stop to do
intensive tasks like that while you're playing samples.
Maybe it could be done with a suitably low sample rate and some
incredibly hairy code that interleaves the sample playback routine with
the IDE reading routine, but it's not something I'd want to attempt
without being completely confident at doing those two things separately.
Having said that, I would quite like to dust off that proto-MOD-player
code some time soon. Even if it's only any use for playing chiptunes
with <30Kb file sizes, that's not such a bad result.
zxbruno
> Doesn't ResiDOS allow direct IO? It's got quite a bit in common with the
> +3e code, and it now supports FAT if I remember correctly. Garry?
I checked the Residos page, and it says it can be used to access FAT16
(not FAT32, as the ZX81 guys do). Gasman, have you tried Residos on
your DivIDE?
I've tried to mount the fixed HDFs with Spin, with no luck. Maybe it's
the wrong version of Demfir, or maybe I need a real DivIDE to see it.
zxbruno
limited by the z80.
zxbruno
longer samples? Would that affect playback?
Matthew Westcott
> Something just ocurred to me. What if we used the 128K memory to store
> longer samples? Would that affect playback?
That would be a good first addition once we had the basic routine going,
yep. The paging logic would add a bit of complexity and possibly slow
the routine down, but it could still work. However, it would probably
only open up another 32K, because we'd have to do everything in
uncontended memory; contended memory accesses would probably slow things
down enough to shift things out of tune. You never know though, maybe it
would still be passable - we'll have to see...
OwenBot
You'd best use the Spectrum SE then. That can give you a full 64K of
uncontended memory with the video paged out. Just page in one of the
sideways RAM banks.