Running TZX off an IDE drive? Or streaming from a NAS?

edited September 2008 in Hardware
Hello.

I know about the DivIDE project, and about the ZX Ethernet project, but not how far they've come or what they can do. So:

1. If I have a squillion TZX files sitting on an IDE HDD can I connect it to a Speccy with a DivIDE and load them as if they're from tape? Or at least, load them? Or can it only run TAP files? Additional: what is the maximum capacity CF card the the CF-IDE can support?

2. If said squillion TZX files are sitting on my NAS, can I connect a cat-5 to my Speccy and stream them off via my LAN, and load them as if they're from tape? Or at least, load them? BTW I'm guessing there's no wireless solution in development, is that right?

3. And how much would the second solution (assuming it is a solution) cost me?

Cheers all
Jon
Post edited by JonNorth on
«1

Comments

  • edited August 2008
    As I understand it, the answer to both questions is "no". The TZX format is just too complicated for a Spectrum to be able to natively interpret it.
  • edited August 2008
    Many things do that with TAP files, and some with TZX. The trouble with TZX files is they often contain some kind of flash loader.

    These things work by trapping the tape load routine, and instead of loading from tape, pass the data contained in the TAP or TZX. TAP files almost always work - TAP only works with the standard load speed, so most things encoded as TAP only use the standard load routine in ROM, which can be trapped.

    All bets are off with a flash loader or custom loader, though, because the address to trap could be anything - and not only that, there are various obfuscation schemes used with many of these loaders. For example, there is a ResiDOS module that supports TZX files - but try and load the Skool Daze TZX with it - it'll get as far as loading the flashloader, then will stop waiting for something coming through the EAR port. This is probably why most people don't bother supporting TZX in hardware - you can only really support the simple case of TZX files (standard loading speed), and why bother supporting the complexity of a TZX file for that, when a TAP file does just as well and is trivially simple.

    The other thing is NAS tends to only support dreadful, RPC based protocols like CIFS which is full of variances and bugs (just look at how big Samba is - it has to support all the quirks of the various buggy CIFS implementations), which will be a royal pain in the butt to support on a Spectrum. My intention is to make a simple network file system for 8 bit systems, and also support FTP.
  • edited August 2008
    Bl00dy hell that was quick!! Morning all!! :) Hey Phil LTNS sir!

    Many thanks for your replies. I think I get it now.

    So what I'm going to need then is a black box which will stream the TZX from my NAS as an audio signal, and output it to the ear port of my Speccy. So a laptop then. :)

    That's pretty much the only solution to this isn't it?
  • edited August 2008
    JonNorth wrote: »
    So what I'm going to need then is a black box which will stream the TZX from my NAS as an audio signal, and output it to the ear port of my Speccy. So a laptop then. :)

    That's pretty much the only solution to this isn't it?

    Basically, yes. The only other thing would be to see which games have cracked .TAP versions available here on WoS and use those instead, which will play directly from a CF card.
  • edited August 2008
    Cool thanks Phil
  • gasmangasman
    is amused by the idea of people telling Jon North how speed loaders work ;-) Yup, as Winston says, ...
    edited August 2008
    /me is amused by the idea of people telling Jon North how speed loaders work ;-)

    Yup, as Winston says, Residos has TZX support, but only for things using the ROM loader (which therefore might as well be TAPs). Also, Residos isn't available for the vanilla DivIDE AFAIK, only for the DivIDE Plus - if that's a factor. Not sure if any other firmwares have plans for TZX support, even at that basic level.

    As for the maximum capacity of CF card supported - I've seen 1Gb+ cards running happily, so I don't think there's any hard limit. Some brands seem to work better than others though, and in some cases they require external power, particularly if they're the 'miniature hard disk in a CF form factor' variety I suppose. (Do they even still make those?)
  • edited August 2008
    I have a divIDE+ and a 512 mb CF card. Switch on, press button on divIDE+, pick game from menu and off you go. I just loaded the card up with TAP files from my PC. The only things missing from this setup is snapshop save and ability to enter pokes, but then you would not have this ability with any sort of TZX streaming anyway.

    Of course you could always plug a small IDE drive into the interface and load that up with TAPS, but 512mb is quite a lot for 48k games.
  • edited August 2008
    gasman wrote: »
    /me is amused by the idea of people telling Jon North how speed loaders work ;-)

    Sorry, I haven't got a faintest clue who Jon North is - sorry Jon if you were at the forefront of flash loader design and I've just insulted your knowledge!
  • edited August 2008
    Winston wrote: »
    Sorry, I haven't got a faintest clue who Jon North is - sorry Jon if you were at the forefront of flash loader design and I've just insulted your knowledge!

    I would asssume Mr North liked the technical answer as it helped explain why its hard to do what he was planning.
  • edited August 2008
    Winston wrote: »
    Sorry, I haven't got a faintest clue who Jon North is - sorry Jon if you were at the forefront of flash loader design and I've just insulted your knowledge!
    What????

    [skarpo mode on]
    The man is a leg-end in his own tea-break.
    [skarpo mode off]
    I wanna tell you a story 'bout a woman I know...
  • edited September 2008
    gasman wrote: »
    /me is amused by the idea of people telling Jon North how speed loaders work ;-)

    *chuckle*

    I know how speedloaders work! (or at least, I did when I was 14, maybe not so much now :)). Just not how the DivIDE interface hijacks the load routines. Makes sense that any non-standard loader would fail.

    What I was looking for was some way of controlling a CF (or whatever) card containing TZX files, but which acted like a tape recorder, ie "playing" them and streaming the audio into the Ear port. Hence my comment about just using a laptop; I just wanted a more elegant solution than another box.
  • edited September 2008
    JonNorth wrote: »
    *chuckle*
    What I was looking for was some way of controlling a CF (or whatever) card containing TZX files, but which acted like a tape recorder, ie "playing" them and streaming the audio into the Ear port. Hence my comment about just using a laptop; I just wanted a more elegant solution than another box.

    That would be excellent if it could be done. You could still load "the original way" (kind of) but without the annoying tape recorder/mp3/audiocd and without having to mess with audio volume.
    I suspect if the divide has access to the ear port, a firmware could do the trick as long as we are talking about simple TZX playing at normal speed, or may be a totally different interface.
  • edited September 2008
    gtsamour wrote: »
    That would be excellent if it could be done. You could still load "the original way" (kind of) but without the annoying tape recorder/mp3/audiocd and without having to mess with audio volume.

    Exactly :) Perfect solution as far as I'm concerned! Question is, does such a device even exist?? (I'm guessing the answer is a flat NO).
  • edited September 2008
    It doesn't for the moment... at least I've never heard of one.
    But if one ever came out, i would definetely buy it because the speccy loading sound has its magic and i would like to have it even if i have to wait for it to load (well sometimes... :D )

    But now that i think of it, i imagine that something like that can't be done by the divide because it doesn't have a sound prodicing cirquit. May be it could send the pulses but no sound would come out of the speccy. But then again i'm not an expert.
  • edited September 2008
    It may be possible to feed "loading sound" as such via the edge connector (and therefore, via some peripheral) but it would require a few interesting little tricks (which, to my knowledge, no hardware as yet does, certainly no mass storage hardware I know of).

    There is an IORQGE line on the edge connector, which functions a bit like ROMCS - you can hold it high and inhibit the ULA. What the hardware peripheral would have to do for loading is this. It would need to intercept the relevant IN instruction for the ULA (due to partial port decoding by the ULA, basically, an IN instruction when address line A0 is low) and hold IORQGE high at this stage, and then provide the expected input onto the data bus that is consistent for what the ULA would be placing on the bus for a high or low state coming from the tape. Once the IN instruction ends, it would then release IORQGE.

    The principle is quite simple, but the devil is of course in the details. Hardware wise it should be possible with a microcontroller (i.e. something that's not the Spectrum's Z80 will need to interpret the TZX file and feed these values for each I/O operation) and a little bit of glue logic hardware (a bit of 74-series logic, or part of the CPLD configuration in a more complex piece of hardware). The software for the microcontroller would be somewhat less trivial (that may be an understatement!), but it should be possible to do with a decent 8 bit microcontroller like an AVR for many common TZX files. Basically, the AVR would have to make sure that when the Spectrum executes the IN instruction to listen to the state of the ear port, the right state is there sitting on its IO pins - essentially, PlayTZX for the microcontroller. The glue logic would be to gate the AVR's IO pins onto the Spectrum's bus when the IN instruction executes.

    You aren't actually producing sound at all, you're just presenting the right input to the CPU during the IN instruction.

    Current hardware out there uses tape traps to load TAP files almost instantly into memory. They typically work by trapping the Z80 executing the tape loader code (you can trap when the CPU is executing at a certain address by looking for the address in combination with the RD and M1 CPU signals). When the hardware sees the instruction fetch, it holds ROMCS high (which pages out the Spectrum's ROM) and pages in its own ROM to the lower 16K, so its tape trap code starts running instead of the normal ROM tape loader.

    For the Spectranet, I have made a programmable trap address, so it is conceivable you could trap flash loaders that run from RAM, but you would have to write a routine for each different type of flash loader (and I bet most of them are relocatable, so you'd end up having to write lots of different ones for each case) - so execution traps aren't really a very good way about dealing with custom loaders! This is before getting onto the various other obfuscation schemes that game loaders use (which you know much more about than I do...)
  • PhuPhu
    edited September 2008
    Winston wrote: »
    You aren't actually producing sound at all, you're just presenting the right input to the CPU during the IN instruction.

    Not produce sound!?!?! Not.... BURN THE HEATHEN!!! j/k :)

    On a serious side, I'm working on such a thing for my laptop project (www.starfleet-net.co.uk/blog - no, its not dead... its just long-time unblogged...). I'm using a PIC18F4520 microcontroller connected to a uALFAT FAT filesystem decoder.

    I've already got C code that does an adequate job of translating TZX into bit sequences (including speed loaders) I just need to bring it all together with a timing interrupt.

    -- Richard
  • edited September 2008
    But we're talking about something simpler than the one Winston describes, something that whould actually produce the sound that a TZX makes when played, and feed it somehow to the ULA to be demoded just as if a real tape was playing (and actually be heard from the Spectrum's speaker).
    Kind of the real thing, not something that uses tricks to bypass the demod process.

    Could this be possible? Its a very original idea I thing and it would definetely sell....
  • PhuPhu
    edited September 2008
    gtsamour wrote: »
    But we're talking about something simpler than the one Winston describes, something that whould actually produce the sound that a TZX makes when played, and feed it somehow to the ULA to be demoded just as if a real tape was playing (and actually be heard from the Spectrum's speaker).
    Kind of the real thing, not something that uses tricks to bypass the demod process.

    Could this be possible? Its a very original idea I thing and it would definetely sell....

    Thats what I was describing in my circuit. The PIC microcontroller would output a signal that could be connected to the EAR socket.

    In terms of design, the two methods (real audio versus bit-on-the-bus) are almost the same thing. Don't forget that filters aside, the entire cassette 'port' consists of tri-stating the CASS/SPKR pin (connected to the EAR socket) onto D6 when A0 = 0, IORQ= 0 and RD =0.

    The only reason you hear the bit stream from the tape is because CASS/SPKR is a dual purpose pin connected to both the EAR socket and the speaker, there's not really a demodulation as such going on (aside from the aforementioned analogue filter circuitry to clean bad signals).

    -- Richard
  • edited September 2008
    gtsamour wrote: »
    But we're talking about something simpler than the one Winston describes, something that whould actually produce the sound that a TZX makes when played, and feed it somehow to the ULA to be demoded just as if a real tape was playing

    You can't do it through the edge connector, you have to do it via the EAR port on a standard Speccy if you wanted to actually feed it "sound". It really wouldn't be any simpler - most of the complexity is in the microcontroller's PlayTZX routine, rather than the hardware. The bit of hardware to respond to an I/O cycle with A0 low isn't very complex at all (it has to only watch IORQ, RD and A0, and gate the microcontroller's output when IORQ/RD/A0 is low - something possible with a single 3 input OR gate controlling a single 3 state buffer, plus a P-channel mosfet to hold IORQGE high during the I/O op)

    If you're just going to feed it actual sound, it's probably easiest to use an iPod as your mass storage device.
  • edited September 2008
    Winston wrote: »
    If you're just going to feed it actual sound, it's probably easiest to use an iPod as your mass storage device.

    I think this is the perfect solution isn't it? The TZX equivilent of an MP3 player which would play any propriatory (ie, TZX, CSW, TAP etc) format, and output the audio to a flying minijack plug which you plug into the Ear port, which gets it's power from the edge connector and which you can connect to a PC to copy the files onto.

    Hah! No chance!!!!!! :)
  • edited September 2008
    What about a custom loader for tzx files on the Divide, ala playtzx or something that can stream the data at a set speed, but not too fast as to trip over turbo loaders. It should read the pulse lengths etc from the tzx to determine speed of streaming each block.

    I'm also thinking about the Codemasters CD loader that used the joystick port with a custom loader. Could this idea be used to stream tzx files?

    There's no reason I can see why you should be limited to using the ear socket, its all 1's and 0's anyway. As long as a custom loader could be written for the Divide.

    I'm trying to think of ways it could be done from a software point of view instead of custom hardware. Even though i haven't a clue as to go about writing a program to do this as I know next to nothing about how tzx files are stored. Maybe I should just sneak off and stop talking about stuff I know not a lot about...
  • edited September 2008
    JonNorth wrote: »
    I think this is the perfect solution isn't it? The TZX equivilent of an MP3 player which would play any propriatory (ie, TZX, CSW, TAP etc) format, and output the audio to a flying minijack plug which you plug into the Ear port, which gets it's power from the edge connector and which you can connect to a PC to copy the files onto.

    Hah! No chance!!!!!! :)

    Well... gasman did that three and a half years ago :-)
  • edited September 2008
    Well... gasman did that three and a half years ago :-)

    I like that! Might have to go and have a little investigate :) Cheers Phil ... and Gasman !

    Quick question: has anything like this been developed for CSW's?

    Additional: is there a Linux port available for the 2nd gen iPod Nano (the tall thin one)?
  • edited September 2008
    Well... gasman did that three and a half years ago :-)

    About TZX.

    miz dawg: i don't understand why i would need a spectrum for this to work. if the software is just an audio file with a bunch of beeps, why can't us windows/mac/linux users just download one of these .txz audio files and put it on our ipod?

    hyarion : it's not... it's binary files that the program converts in real time to audio...

    Gasman :...And isn't that exactly what an MP3 player does?

    Yes, strictly speaking, you don't need a Spectrum for this to work, depending on your definition of 'work'. You can download a bunch of .tzx files and listen to them on the bus, if listening to a load of beeps and squeals is what floats your boat. It's just that the beeps and squeals have more long-term entertainment value if you replay them into a Spectrum, rather than your ears. icon_smile.gif

    LOL

    But really, some people are just too clever.
  • edited September 2008
    FrankT wrote: »
    There's no reason I can see why you should be limited to using the ear socket, its all 1's and 0's anyway. As long as a custom loader could be written for the Divide.

    The trouble with it is custom loaders are expecting the 1s and 0s in a very specific manner, and in a slightly different way for each different flash loader, and some of them have nasty little encryption schemes - and they only work if the data arrives on the data bus in response to the right IN instruction. (I touched on this when discussing the programmable trap earlier in the thread). By the time you've made custom tape traps for every custom loader out there, well, you may well have just loaded the game into an emulator and saved a snapshot, which the DivIDE already handles with aplomb. Or found a TAP version of the program, which the DivIDE also handles.

    To actually feed a TZX file to a Spectrum, apart from the simple case where only the standard ROM loader is used, you're going to need a separate CPU of some sort on which an effective implementation of PlayTZX runs.
  • edited September 2008
    aowen wrote: »
    I don't see why the internal Z80 couldn't be used to decode the TZX and push the data to the right places

    What are you proposing to trap to implement this mechanism? I can't think of anything that would work.
  • edited September 2008
    aowen wrote: »
    I don't see why the internal Z80 couldn't be used to decode the TZX and push the data to the right places, providing some additional RAM was available as a buffer.

    1. The right places aren't known, without analyzing the flash loader code.
    2. The data might have various other obfuscations, such as encryption, meaning also the cipher must be analyzed if it's dependent on things set up by the flash loader and perhaps how much time has elapsed.
    3. I've not looked at loaders, but I bet my assumption that they are relocatable and multiple versions exist of the same brand of loader is a pretty reasonable one, making it hard to make generic code that can handle (1) and (2).
    4. Even if you have lists of addresses to trap for all loaders, existing IDE hardware only traps fixed addresses, and in ROM only.

    By the time you've dealt with (1), (2) and (3) it would have been far easier and more practical to just load the program in an emulator and save as a snapshot which the DivIDE can use, or hack the game (which is essentially what you have to do to find out 1, 2 and 3) and convert it to a TAP file, which the DivIDE already handles.
  • edited September 2008
    Winston wrote: »
    3. I've not looked at loaders, but I bet my assumption that they are relocatable and multiple versions exist of the same brand of loader is a pretty reasonable one, making it hard to make generic code that can handle (1) and (2).

    Indeed. The logic behind the Multipokes that Graham Mason and I wrote back in the day assumed a line of data for each implementation of whatever protection system it was for, which contained the values of the variables. Making a box which contained logic to handle every implementation of every protection system, whilst not impossible, would certainly be unworkable to the level of pointless - it's just too big.

    My idea behind this TZX implementation was simply a box to feed the audio to the ear port, which seems to have been done very elegantly with Gasman's mods to the Linux iPod port - not to try to hijack every loading system!

    Hey Gasman, is there any implementation of CSW file handling in that TZX patch of yours at all?
  • edited September 2008
    aowen wrote: »
    The thing is, if you can't flashload the TZX then it's going to be quicker to use a Z80 snapshot or a .TAP file that can be speed-loaded. The whole point of having IDE was more about fast access and less about massive storage space.

    Oh I see! I think that's where the confusion lies: my point of using IDE was ironically the opposite: I wanted to load the games as if from tape but have them all stored in a small black box. Apparently, a black box the size of a 4Gb 1G iPod Nano running Linux :)
Sign In or Register to comment.