Denial

eslapion wrote:

groepaz wrote:... and they run at typically twice that temperature.... oh well

Twice 300K would be 600K, that's 327 Celcius...

I don't know of any hard drive that runs at the temperature of a soldering iron...

Me neither, but I remember the large Wincester disks of the IBM System/36 at my old workplace. They were quite hot, but less than 120C I would say.

Another thing to consider is the development of tapes media at the end of the 80'ies. Not that it affects the discussion here, but improved magnetic coatings made it possible to get higher density as a thinner coating also meant that magnetic domains could be smaller. I think I actually had a recorder that could run at half speed at some point (for audio tapes). But for a thinner coating to work, the tape head also had to be made accordingly (as for the disk drives). This technology was later used for improving hard drive storage density.

Sorry, just one of my digressions.

Sweet, a turboloader!

That being said, we still don't know the optimum encoding frequency for the datasette filter integrator.

...

pixel wrote:The loader itself is about 660 bytes, so it takes longer than the main file to get in. 10.9K compressed Super Starship Space Attack makes it in 20s.

In the meantime I made myself the fun to hear into the *.wav at low volume.

It really has the same sounds when dialling in with a 56K where the first parts are sent at low Baud rate and then the modulation is changed and only noise is anymore heard. Well done!

Some ideas to improve on the load time of the tape routines:

- the lead in could be shortened to 1 second,
- the tape header can contain code after the file name,
- I'm not quite sure about that, but maybe one can omit the most part of the header copy by sending a premature file end signal,
- same applies to the payload, here the copy definitely can be omitted - the ?LOAD ERROR is irrelevant here.

With the tape header, the first part of code can be loaded to $0351..$03FB (171 bytes), and ideally the payload should be loaded to $02A1..$0303 (95 bytes payload + 4 bytes extra data), where $0300/01 contain the original value of the BASIC error vector, and $0302/03 a changed value for the BASIC warm start, so the fast loader is entered with an autostart procedure.

This gives you 266 bytes with the KERNAL load speed to play with.

http://sleepingelephant.com/ipw-web/bul ... .php?t=692

Mike wrote:- the lead in could be shortened to 1 second,

That's true but it goes well with recording real tapes from the start as it is.

Mike wrote:- the tape header can contain code after the file name,

Have practised that thoroughly. But I prefer to have model detection in there. That's why "Pulse" loads on any machine.

Mike wrote:- I'm not quite sure about that, but maybe one can omit the most part of the header copy by sending a premature file end signal,
- same applies to the payload, here the copy definitely can be omitted - the ?LOAD ERROR is irrelevant here.

The KERNAL doesn't like that but I'll look into it.

Thanks for the contributions btw!

Mike wrote: - I'm not quite sure about that, but maybe one can omit the most part of the header copy by sending a premature file end signal,
- same applies to the payload, here the copy definitely can be omitted - the ?LOAD ERROR is irrelevant here.

The KERNAL doesn't seem to like tricks like that. Instead I replaced the repeated data by (at least) two zero bytes and it went through without LOAD ERROR on the real thing. I've updated the zip but tuned it down to 3.6kbit/s – that killed the extra seconds though.

pixel wrote: I replaced the repeated data by (at least) two zero bytes and it went through without LOAD ERROR on the real thing.

That's actually what I meant - truncate the copy as much as possible (say, after the 2 bytes you used) and 'just' end it prematurely with the lead out signal. I just wasn't quite sure if this also works with the header part.

Regarding the modulation: this thread on Forum64 should also give some insight, especially on the second page:

https://www.forum64.de/index.php?thread ... r-via-pwm/

Mike wrote:Regarding the modulation: this thread on Forum64 should also give some insight, especially on the second page:

https://www.forum64.de/index.php?thread ... r-via-pwm/

OneBitman mentions a "cutoff" frequency of 4kHz - in engineering terms, cutoff refers to -3dB reduction in amplitude (50%) vs normal amplitude.

I think what you have to look for is the frequency which provides the peak amplitude, not the -3dB bandwidth. IMHO, the peak amplitude frequency will provide the most resilient signals.

@pixel:
On the hardware side, would you be interested in experimenting with a modified datasette in which the tape goes faster and the integrators are modified to allow a higher frequency ? Then perhaps it would be possible to push the data rate up to 6kbit/s, maybe even higher ?

Added edit:
@Mike: Did you take a look at this ? ftp://ftp.zimmers.net/pub/cbm/schematic ... update.gif

If you change C4 to 470pF then this means this integrator can only perform it's job properly at a rather low frequency. The cutoff for IC2-A is around 6kHz so normal gain (56/3.9=14.36) should be around 3kHz.

eslapion wrote:OneBitman mentions a "cutoff" frequency of 4kHz - in engineering terms, cutoff refers to -3dB reduction in amplitude (50%) vs normal amplitude.

I think what you have to look for is the frequency which provides the peak amplitude, not the -3dB bandwidth. IMHO, the peak amplitude frequency will provide the most resilient signals.

@pixel:
On the hardware side, would you be interested in experimenting with a modified datasette in which the tape goes faster and the integrators are modified to allow a higher frequency ? Then perhaps it would be possible to push the data rate up to 6kbit/s, maybe even higher ?

I remember in the days of the Amiga when I played with floppy disk encoding routines to increase data density. On the floppy drives one had to insert bits in between the databits in order for the read/write to work. The reason was that too many 0's or 1's would result in lost syncronization, so for example 0000 would become 01010101 and 1111 would become 10101010 before they were written. All-in-all this increased the stored bits by 100%, so I made a method that would encode the data to ensure that it never contained three succeeding 1's or 0's by making a byte into 12 bits. It worked very well, efficiently increasing the storage capacity by 50%.

Now, if you could somehow use this in the opposite way to prevent 1 and 0 coming too often after each other, you would effectively reduce the bitstream frequency. I have no idea if you can manage to reduce the frequency by 50% without increasing the datasize by 100%, but given that you double all 0's to 00 and all 1's to 11, that is the worst possible outcome. Since there are many patterns in which .010. or .101. doesn't occur too often, it may be possible to gain some improvement in data density in this way.

@Kakemoms: ever heard of GCR ?

eslapion wrote:@Kakemoms: ever heard of GCR ?

Sorry, I can't remember much details. I remember the Amiga had some complicated encoding scheme which was probably called that.

I guess the trigger and speed is just right with all the leakaritis inside the vics. I guess one could do horizontal pixelwise shift on crtcs by spoiling the vsync with a well-defined memory access.

pixel wrote:I guess the trigger and speed is just right with all the leakaritis inside the vics. I guess one could do horizontal pixelwise shift on crtcs by spoiling the vsync with a well-defined memory access.

As long as you don't forget to recalibrate the phase grids every now and then, indeed.

First of all, cool that you do new approaches to tape loading!

pixel wrote:

Mike wrote:- the tape header can contain code after the file name,

Have practised that thoroughly. But I prefer to have model detection in there. That's why "Pulse" loads on any machine.

The original tape loader for Super Starship Space Attack (which is the same loading system as on Pentagorat) has a small bootloader (~128 bytes) in the tape header which is model agnostic. This quickly loads the main irq loader using a turbo tape protocol.

You could do the same to load up your main loader.

pixel wrote:

Mike wrote:- I'm not quite sure about that, but maybe one can omit the most part of the header copy by sending a premature file end signal,
- same applies to the payload, here the copy definitely can be omitted - the ?LOAD ERROR is irrelevant here.

The KERNAL doesn't like that but I'll look into it.

This can be done by using IBREAK autostart. IBREAK will get called directly after it's been written the first pass so the next pass can in theory be omitted.

I remember the Amiga had some complicated encoding scheme which was probably called that.

amiga disks use MFM, not GCR