Jump to content
IGNORED

Draconus 4 CAS file at 1400 bps.


Wilheim

Recommended Posts

Hello, everybody!

 

Back in the late 80s and early 90s, in my country there were a lot of Atari "distributors" who published their games using propietary loaders. Basically they were XEX loaders and sometimes they adapted the binary files so they can work with their loaders.

 

In this case, I want to present you an example of this: there was a format that was called "NHP" (meaning "No Hay Problema"/"No problem", citing a catch phrase from the character ALF).

 

The format has some features:

 

- Uses tape blocks of 257 bytes instead of 132.

- It has an identifier for each block, so if there's an error during the load, you can resume it by rewinding it a little, pressing play again and resume the load.

- Has a block counter, so you can know how much tape is left to run.

- Can run at speeds from 600 bps to 1400 bps.

 

In this case, I attached an example of a CAS file of a game that loads at 1400 bps. The original one takes about 16 minutes to load. This version takes only 4 minutes and 14 seconds.

 

Please remove the TXT extension before running it.

 

Hope you like it and any comment is welcome!

Draconus 4 NHP 1400 bps.cas.txt

  • Like 6
Link to comment
Share on other sites

Found the problem - was using 2.7. Tried again with 3.0 and is working.

 

Interesting - assuming it is accurate emulation it does seem twice as fast.

Does this system still use framing bits? To do so you'd have to bit-bang the whole lot.

 

In my experiments years ago I did and used for some time, a loader + 8K single block image of the AtAsm cart which loaded pretty quickly (largely thanks to getting rid of the IRGs).

But I don't think I ever got reliable reading at much over stock speed, maybe something like 800-850 bps (and that was using stock records/IRGs).

Edited by Rybags
Link to comment
Share on other sites

Back in the day, I always found the weakest part of the Atari experience was cassette I/O.

 

Unfortunately as I only bought original games (yes, seriously) back then, I never experienced any of these clever loaders.

 

An interesting development on the Atari front now would be a PC based tool which creates tapes like this with plenty of radio boxes asking questions like:

a) Do you want a loading picture? If yes, supply a file.

b) Offering options like "With compression / without compression"

c) Whether there should be music on the loading screen.

d) Offering cheats

e) Whether there should be a downwards timer or a downwards block counter

f) Design your own loading screen

g) Select your own compression system if using compression, potentially testing several of them to see which one produces the shortest one.

h) Silent (poke 65,0) or noisy load

i) Offering to overlay a .wav or .mp3 file over the sound track.

  • Like 2
Link to comment
Share on other sites

The only attraction for me with tapes in the modern day is the technology behind the various turbo schemes and that's just a technical interest.

 

As for enduring even a 4x speed load of a game, not really interested much. I've got a 1010 and 410 and last used either for the audio via motor control stuff. I do suspect that the belts on both of them are probably held in place by a hair and will break at the first attempt of real usage anyway.

  • Like 1
Link to comment
Share on other sites

Back in the day, I always found the weakest part of the Atari experience was cassette I/O.

 

Unfortunately as I only bought original games (yes, seriously) back then, I never experienced any of these clever loaders.

 

An interesting development on the Atari front now would be a PC based tool which creates tapes like this with plenty of radio boxes asking questions like:

a) Do you want a loading picture? If yes, supply a file.

b) Offering options like "With compression / without compression"

c) Whether there should be music on the loading screen.

d) Offering cheats

e) Whether there should be a downwards timer or a downwards block counter

f) Design your own loading screen

g) Select your own compression system if using compression, potentially testing several of them to see which one produces the shortest one.

h) Silent (poke 65,0) or noisy load

i) Offering to overlay a .wav or .mp3 file over the sound track.

This is not much matter of PC programming, but matter of programming a loader or loaders with all the features. Of course, binary load files with init segments would provide a tough resistance.

 

Believe it or not, most of the mentioned features were planned for Standard Plus plugin for Turgen System. But that effort is on hold indefinitely.

Link to comment
Share on other sites

I still love tape. Not that I use it a lot. But I notice that I do not jump from game to game since I waited so long for the game to be played so I appreciate it more. At certain level this also applies to stock disk drive loading. Of course just like Stephen I am spoiled too with flash carts like The!Cart, MyIde, IDE+ and SIDE2. But TBH: I switch games pretty fast on those solutions too. So tape has definitely a charm.

Link to comment
Share on other sites

Don't you love how being a retro nerd makes you slower and a bit of a liar in some cases..

 

He we are spoilt with SSD's etc and now we sit and boot up games at disk speed on an Atari and even aspire to relive the various drives and loaders to 'keep it real' :)

 

And then there's liar bit, now most of us started from tape and got a drive as soon as we could, well not Baktra, he loves tapes :) and good luck to him, total dedication. Now we got the drive and most of us sat down and said "thank goodness for that, I'm NEVER going to use a tape again" and yet here we are thanks to the emulation and the encouragement of others actually enjoying tapes again in a reasonably big way. I'm sure the novelty for me will wear off soon but its just refreshing to have a more grown up view of the tapes and their many workings and loaders.

 

So thanks to all the 'Tapists'...er that sounds a bit wrong, try Tape connoisseurs for helping and getting Avery to expand the tape role in Altirra and of course Avery for the extra hard work getting it all going as he's no fan of tapes :)

  • Like 2
Link to comment
Share on other sites

I had an XC12 and I used to return a lot of cassettes to my main shop in Tamworth, UK. I think that they thought that I was copying their games, but this wasn't the case, I just returned a lot as they just wouldn't load.

 

Then one time they asked to take a look at my XC12 as they could "fix it". Two weeks later they'd done nothing to it and had to return it. I think that they were just stopping me from purchasing/returning any.

Link to comment
Share on other sites

Well,

 

Abbuc floppydoc just found out that the (load/save) routines for C: work fine on NTSC machines, but were not changed for PAL machines, which is one cause for increased loading and saving errors. He calculated the correct value for PAL and then changed his OS accordingly and suddenly a tape that gave several tape errors before, did not give any errors anymore (he tested this 10 times). He is now examining the PAL XL OS for more C: errors or imprecise values...

 

There was also an article in the old (german) Atari Magazin about CBaud by Arndt Baer (a type-in program that increased the loading/saving speed from 600 to 1200 Baud by software only), where Arndt found some other imprecise or in-effective C: values in the OS and changed this in CBaud for a better data transfer.

 

So, thanks to some OS bugs and/or imprecise values in the (PAL) OS, we PAL Atarians do have less luck loading a tape without getting a tape error (e.g. Error 143), even if the tape is fully okay...

  • Like 1
Link to comment
Share on other sites

The tape version were sometimes better than the disk versions, as they sometimes had more data, and more was included for cheap... the other plus for cassette was the audio track for learning languages and some other select games and applications... Lets not forget some of the very new and cool Demos... like the silly venture bad apple... loading music was nice some times as well... learning tapes were just cool.. All that said...Once folks learned how to cram more info on a disk and we had bigger faster storage... many conversion from tape to disk were done... there were some experiments on saving audio to floppy out there but not much came of it... a search will show some more modern day pc floppy attempts at it.

 

Still would love a cas device that does the audio track though...:)

Edited by _The Doctor__
Link to comment
Share on other sites

I remember that I used 'The Happy Turtle' a lot when I owned my 800XE with XC12 without any hw mod. Many programs could load with double speed. The loader had 15 counts in normal speed.

Many programs could load faster but it had no rewind option.

This loader is much advanced as you can rewind when error and can load faster. Nice thing, if I had this from 1988 till start of 1990 when 'the Wall' caused that I had no chance to buy a disc drive.

  • Like 2
Link to comment
Share on other sites

Well,

 

Abbuc floppydoc just found out that the (load/save) routines for C: work fine on NTSC machines, but were not changed for PAL machines, which is one cause for increased loading and saving errors. He calculated the correct value for PAL and then changed his OS accordingly and suddenly a tape that gave several tape errors before, did not give any errors anymore (he tested this 10 times). He is now examining the PAL XL OS for more C: errors or imprecise values...

 

There was also an article in the old (german) Atari Magazin about CBaud by Arndt Baer (a type-in program that increased the loading/saving speed from 600 to 1200 Baud by software only), where Arndt found some other imprecise or in-effective C: values in the OS and changed this in CBaud for a better data transfer.

 

So, thanks to some OS bugs and/or imprecise values in the (PAL) OS, we PAL Atarians do have less luck loading a tape without getting a tape error (e.g. Error 143), even if the tape is fully okay...

 

Good you take that point. As a matter of fact, when we recover an old XEX loader, I noticed that there were some issues with the timers between PAL and NTSC. I had to patch some places in the OS ROM to fix them and now this copier works on both standards.

 

Link: http://retrogames.cl/foro/viewtopic.php?f=21&t=12931

  • Like 1
Link to comment
Share on other sites

..., well not Baktra, he loves tapes :) and good luck to him, total dedication.

Thank you. In fact, I do not like tapes that much, but I loved working on a tool that can be used to create tapes with convenience even today. And I liked the "smell" of freshly recorded tapes with games ready to be sent to a person who ordered them. But these days are over, the tool is good enough now and will be around for a while.

 

It is too bad Atari "spoiled" the tapes from the beginning by low base speed and bugs in the OS. I understand that 600 bps was a lot in 1979, however the XL line could have come with upgraded OS and upgraded data recorders that would do 2400 bps (enough for a small computer system) still using the same modulation. However, foreseeing the future is always very difficult. The disk drives took over and the turbo upgrades were just response to a specific situation in specific markets.

Edited by baktra
  • Like 1
Link to comment
Share on other sites

Zx spectrums i believe can go up to 19200 on audio based data loaders capable ( ie tapes/audio/data based in sequential loading blocks).

However reliability at these speeds means tape reliability wont be up to this. Wav loading from pc is amazing as loading screens appear almost instantly.

 

Does anyone know what the fastest speeds the A8 was built to cope with?

Link to comment
Share on other sites

Yeah sad that we never got software Turbo Tapes.

 

But 4 min vs 14min is quite good only by software? Reliable?

 

Errrm well,

 

there were not many commercial turbo tapes in our western world, that is true. In the 80s, most companies used larger blocks (e.g. 256 Bytes, 512 Bytes, 1k , 2k, etc.) instead of higher Baudrate, but my tape2disk project has shown, that at least Gremlin Software used turbo tape with approx. 800-900 Baud with "Zone X". The tape has a timer and on one side it says something like 9:40 loading time, while on the other side it has approx. 6:40 loading time and you can clearly hear the higher pitched Baudrate... (while it still uses standard block length)...

 

In the 90s dozens of turbo tape schemes were available and e.g. Derek Fern / Microdiscount sold some tapes commercially in turbo tape format (Rambit turbo tapes, he also sold the hardware), maybe some other western publishers did this too and I am quite sure that some of the eastern publishers from Poland, Czechoslovakia, etc. did that also.

 

But most (western) Atarians upgraded from tape to disk as fast as possible and so there was no real requirement to support turbo tape format in the western world. There were however several software based turbo programs available, e.g. Filemover (a C/D copy program, loads+saves with 600 or 800 baud), Speed Tape (type-in listing, loads+saves with approx. 1000 Baud) and CBaud (another type-in listing, loads+saves with approx. 1200 Baud) to name just three programs. But the interest was just not there and so only pirated file copies of games were available in the western world as turbo tapes (and as a former A8 tape pirate in the 80s, I can say that 99% of pirated tapes I have seen still used only the standard 600 Baud format with standard block length)...

 

In eastern Europe, Asia, middle+south America however turbo tape became more or less a standard, alas, not one standard, but dozens of different turbo tape standards evolved. Don't know which one was/is the fastest one regarding baudrate or block length, nor which one was the best one or most reliable one... maybe Baktra has some objective data available there...

Link to comment
Share on other sites

The turbo systems do not have a clear winner, because there are several areas in which the turbo systems can excel or fail.

 

1. Transfer speed (ranges from 900 to 9600 bps). Transfer speeds above 6000 bps are rare and require data recorders in perfect shape. For long-term practical usage, 3600 bps is a good maximum.

2. Possibility to load binary load files without modifications. Some turbo systems simply lack this ability.

3. Possibility to use the system through CIO (exposing T:, B: or D: device)

4. Overall quality and versatility of the accompanying software (loaders, copiers, tape operating systems)

5. System requirements (RAM under ROM usage, buffer sizes, loader sizes), availability of the software on cartridge

6. Number of available and standardized file formats.

 

In my opinion, the ideal turbo system would offer the following:

 

1. Three standardized file formats - plain monolithic file (equivalent of a boot file), kilobyte blocks (for use through CIO), format for binary load files (for quick loading, pilot tone needed only for INIT segment)

2. At least two transfer speeds - 2400 bps and 3200 bps

3. Electric switch between turbo and standard mode

4. Comprehensive set of loaders and copiers with extra low memory footprint loader

Edited by baktra
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...