Turbo Cassette

discussion of beeb/electron applications, languages, utils and educational s/w
jdavis6809
Posts: 13
Joined: Sun Jan 31, 2016 12:19 pm

Turbo Cassette

Postby jdavis6809 » Tue Apr 12, 2016 7:46 am

Hello All,

Anybody got anything on how to increase cassette speed (ie x 10) record and playback on mp3 player, BBC or Electron

C64 has a turbo cassette system, but I have not seen anything for BBC / Electron

google comes up with nothing

Regards

John

Electron and Plus 1

User avatar
tricky
Posts: 1922
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Turbo Cassette

Postby tricky » Tue Apr 12, 2016 8:26 am

Looks like RichTW did some experiments, I can't find his newer posts, where I thought that he had a turbo tape loader, but this might get you started http://stardot.org.uk/forums/viewtopic.php?f=2&t=3720&p=31765&hilit=turbo+loader#p31754. It looks more about compression, but I'm sure Rich would have considered all aspects.

User avatar
richardtoohey
Posts: 3378
Joined: Thu Dec 29, 2011 5:13 am
Location: Tauranga, New Zealand

Re: Turbo Cassette

Postby richardtoohey » Tue Apr 12, 2016 9:22 am

Don't have answers, but found a couple of things on the internet (well, OK, the first two hits!) about the C64 loaders:

https://en.wikipedia.org/wiki/Fast_loader
http://www.atarimagazines.com/compute/i ... otape.html

An interesting question, hopefully someone can answer with the real details ... :D

User avatar
1024MAK
Posts: 6799
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...

Re: Turbo Cassette

Postby 1024MAK » Tue Apr 12, 2016 9:29 am

Because of the way that the cassette interface works (it uses the serial port chip and a ULA in the BBC and the ULA in the Elk), the options for speeding it up are limited.

Users that could afford it, quickly moved to using disk drives. The disk drive system on the BBC and Elk is quick. It being a proper Shugart type floppy disk system at the hardware level. Acorn wrote it own software, it's called DFS. Then later wrote an advanced version called ADFS.

Now, for fast loading, most users either use a SD card (MMC card) or use a custom serial lead called UPURS. For the BBC, there are also hard drive systems and CF storage systems (which pretend to be hard drives).

So the cassette interface is not often used by very many people anymore. Hence you not finding much information on a turbo cassette system.

If you want any information on any of the storage systems or UPURS that I mentioned, either browse / search the forum, or failing any luck with that, shout out. Either me, or some very friendly and knowledgable members will be happy to help.

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

User avatar
CMcDougall
Posts: 5623
Joined: Wed Feb 02, 2005 3:13 pm
Location: Shadow in a Valley of Scotland

Re: Turbo Cassette

Postby CMcDougall » Tue Apr 12, 2016 7:51 pm

the post by RichTW is here:
http://www.retrosoftware.co.uk/forum/vi ... urbo#p4693
and I got it to work on an actual beeb 8)

other loaders could be stream loaders like on Firebird / Ultimate original tapes, as no 3 seconds of space between blocks....
but never 10x quicker, unless can get 12,000 baud :^o

Welcome BTW John, have fun with your elk! =D>
ImageImageImage

User avatar
roland
Posts: 2808
Joined: Thu Aug 29, 2013 8:29 pm
Location: Born (NL)
Contact:

Re: Turbo Cassette

Postby roland » Tue Apr 12, 2016 9:49 pm

On the Atom we had mjcos, a cassette operating system up to 9600 baud. The dutch documentation and source code is at http://acornatom.nl/atom_nieuws/1983/nr5/19835019.htm

It uses the via so porting it to an Elk is a bit difficult but a beeb might be able to handle it. I did use it in the past and it worked quite well.
256K + 6502 Inside
MAN WOMAN :shock:

paulb
Posts: 784
Joined: Mon Jan 20, 2014 9:02 pm

Re: Turbo Cassette

Postby paulb » Tue Apr 12, 2016 11:08 pm

CMcDougall wrote:other loaders could be stream loaders like on Firebird / Ultimate original tapes, as no 3 seconds of space between blocks....
but never 10x quicker, unless can get 12,000 baud :^o


I remember a program in Electron User that reduced the inter-block gap to the supposed non-zero minimum. I suppose it made loading somewhat faster, and maybe a few games also used a variation of that trick. Disks and cartridges were the way to go for faster loading, however.

ThomasHarte
Posts: 367
Joined: Sat Dec 23, 2000 5:56 pm

Re: Turbo Cassette

Postby ThomasHarte » Wed Apr 13, 2016 2:11 pm

Speculative, but...

I would be very surprised if the Electron's shift register for incoming tape data weren't readable at all times — always shifting away, signalling interrupts only when appropriate start/stop conditions are met.

If that's true then, as a start, one could dispense with start/stop bits. You probably still want a prefix code as exact tape timing varies from deck to deck but you get that anyway if you use a Huffman tree, and you were probably going to use compression anyway, and arithmetic coding would probably just add as much in processing as it reduces in storage.

If you needed to retain high tone sections, each of those could probably be ten bits only — just enough to be explicit that there's no start/stop coming.

There's also the question of timing. Both machines have to allow some flexibility here. In addition to the actual on-tape bit encodings, one could add an additional channel of information by varying their exact lengths, which would be decoded by timing the inter-[bit/byte] periods. There are around 16,666 cycles on the 2Mhz bus per byte, which would still be 13,333 even if start/stop were eliminated, so probably on-CPU counting would be sufficient — which is lucky if you're targeting the Electron. With just had four different lengths of byte you've added two extra bits in the side channel.

With those two things together then, eight bits of data used to take 16,666 cycles to store; in 16,666 cycles you now get 11.25 bits. Which is a close to 40% increase.

... so nowhere near 10x faster.

dixiestoat
Posts: 248
Joined: Tue Oct 09, 2012 8:58 am
Location: Warwickshire

Re: Turbo Cassette

Postby dixiestoat » Wed Apr 13, 2016 4:04 pm

Didn't some "later" Electron games use the short beeeep in between the data bursts?
I seem to recall some games only having a very tiny beep in between the "noise.."

They did seem to load quicker. Less wasted beeping time i guess..? :?
If in doubt, CTRL-BREAK thou should clout..

User avatar
oss003
Posts: 2554
Joined: Tue Jul 14, 2009 11:57 am
Location: Netherlands
Contact:

Re: Turbo Cassette

Postby oss003 » Wed Apr 13, 2016 4:42 pm

There is done some experimenting in the past on the Atom with a turbo cassette system and there are 3 major turbo upgrades: 3000, 6000 and 9600 baud. The trick is to connect the shift register of the 6522 to the cassette port. However, you do need a good cassette recorder system to read/write reliable data.

3000 baud: http://www.acornatom.nl/atom_nieuws/198 ... 834063.htm
6000 baud: http://www.acornatom.nl/atom_nieuws/198 ... 835017.htm
9600 baud: http://www.acornatom.nl/atom_nieuws/198 ... 835019.htm + http://www.acornatom.nl/atom_nieuws/198 ... 836017.htm

Greetings
Kees

User avatar
roland
Posts: 2808
Joined: Thu Aug 29, 2013 8:29 pm
Location: Born (NL)
Contact:

Re: Turbo Cassette

Postby roland » Wed Apr 13, 2016 9:11 pm

From 300 baud to 3000 baud is 10x quicker :lol:
256K + 6502 Inside
MAN WOMAN :shock:

jdavis6809
Posts: 13
Joined: Sun Jan 31, 2016 12:19 pm

Re: Turbo Cassette

Postby jdavis6809 » Thu Apr 14, 2016 10:14 am

Hello

The way Oric Atmos does it is

The forum group produced a windows programme that converted a normal speed tape file to be increased by 10 with a small loader running a normal speed then you converted it to a wav file to play back on a mp3 player.

So when you run programme the loader sets the tape speed x 10 then the file is loaded x 10 speed I know this works because I had Atmos

see attached then you will understand

john
Attachments
tap2cd readme.txt
(6.04 KiB) Downloaded 30 times

User avatar
danielj
Posts: 5367
Joined: Thu Oct 02, 2008 4:51 pm
Location: Manchester

Re: Turbo Cassette

Postby danielj » Thu Apr 14, 2016 12:59 pm

Looks to me like the ORIC used a 6522 for its tape interface, and as we know that can be used to bit-bang at ridiculous speeds :D

The Elk (and beeb) just physically can't do it.

d.

ThomasHarte
Posts: 367
Joined: Sat Dec 23, 2000 5:56 pm

Re: Turbo Cassette

Postby ThomasHarte » Thu Apr 14, 2016 1:54 pm

danielj wrote:Looks to me like the ORIC used a 6522 for its tape interface, and as we know that can be used to bit-bang at ridiculous speeds :D


... subject to the two famous shifter bugs*, of course. Derive your CB1 from ø2 or end up with a disk drive that takes more than two minutes to load 64kb**.

* intentionally plural despite the urban legends; see the Synertek data sheet.

** around 4,400 bits per second, slower than the turbo tape solutions mentioned for other platforms above.

EDIT: also, if you're assuming audio provided from a CD, which eliminates all variations in playback speed, I would dare imagine you could get a much more helpful length-of-byte side channel. So ditch start and stop (and therefore interrupt-driven loading), acquire a 4-bits-per-byte side channel (a completely invented number — does anybody know the real tolerances on baud rate? Can the machine make sense of 1100 baud? 1000 baud? 1300 baud?), and you're getting 17.5 bits where you once got 8. That's pretty good. And pretty good evidence that amazing programming feats are really easy if you never actually perform them.

If somebody with a real machine can figure out the least and greatest baud rate that falls within the acceptable tolerances, I can have a go at the rest via emulation.

JoolsH
Posts: 423
Joined: Mon May 21, 2012 11:46 am

Re: Turbo Cassette

Postby JoolsH » Fri Apr 15, 2016 7:12 pm

I reduced the inter-block gaps on the tape version of Mixed Grill March from 0.8 to 0.4 seconds or so - wav available here: http://www.retrosoftware.co.uk/wiki/images/9/94/MixedGrillMarch_v1.01_turboload-wav.zip

It was a bit tedious, because I did it manually in an audio editor. Still, the game loads in under two minutes.

When I was messing about with copying a few Electron games onto audio CD in 2000 or so, I also found that you could speed them up by 5% or so, and they would still load. Not the sort of thing you want to do with tape, though, because it reduces your margin of error on the speed of the playback tape drive.

ThomasHarte
Posts: 367
Joined: Sat Dec 23, 2000 5:56 pm

Re: Turbo Cassette

Postby ThomasHarte » Fri Apr 15, 2016 8:44 pm

Oh, ouch, something like 1264 baud is the maximum? That's a very thin tolerance.

I really think this is an area where Acorn over-designed and thereby obstructed.

EDIT: that being said, back-of-an-envelope calculations:
  • suppose you're running at 1Mhz, because I'm working on an Electron scheme;
  • at the perfect 1200 baud you're therefore getting 833 CPU cycles per bit;
  • for argument's sake, assume that the tolerances are per-bit and that the tape data register is the most obvious implementation: an 8-bit window into a 10-bit shift register that therefore visibly shifts as data loads;
  • if you dare to go 2.5% faster and 2.5% slower, in an attempt still to be take deck compatible, that's a total 5% variation, i.e. a difference of 41 cycles;
  • a tight counting loop would therefore implement a counter, then read from the tape register, compare to the old value, store and zero the counter if the register has changed, continue;
  • such a loop would normally be 5 (read-modify-write zero page) + 4 (read register) + 3 (compare to a zero page value) + 4 (branch) = 16 cycles, long enough that an 8bit counter wouldn't overflow and more than short enough to exceed Nyquist on testing for a 41-cycle difference;
  • the 8-bit counter would prima-facie go up to around 52, so there's probably time to decode the side-channel byte (eight loads, compares and rolls, so 88 cycles, plus time to deposit two bytes into memory) as the next bit starts; but
  • in the most naive scheme, that would require a fake bit to be inserted any time there are 8 in a row with the same value, so assume that happens 2/256th of the time (i.e. after every 0 or 255-value byte).
... then by taking the value of each stored bit as (i) the bit on tape; plus (ii) an extra bit determined by whether the bit length was close to the low tolerance or close to the high tolerance, having discarded starts and stops, with 1 in 16 bits being lost 1/128 of the time (so, one in 2048 bits being redundant), you get an average data throughput of...

2398.82 bits per second.

Probably you'd end up not using the side-channel bit on the synchronisation bits though, because it'd be really painful to decode. So 2397.66.

Dropping to 2133 bps if you have a lot of zeros or 255s in a row, rising to 2400 if you have none. So possibly you'd put a constant XOR mask into the file header to deal with painful cases?

Then you might try to squeeze all of that into the bottom of the stack page, as a prefix loader in normal ROM format, that then does its own thing to load the real data.

I can't immediately think of a way to make it transparent though without implementing a filing system ROM for LOADed content. CHAIN and *RUN could just be the turbo loader that then loaded the turbo code.

With no current access to real hardware, at some point I shall endeavour to implement CSW support in my nascent emulator and give it a go. It strikes me that a likely false presumptions is that the ideal baud rate around which to space is 1200 baud (1200 is probably within tolerance, but it doesn't evenly divide any of the system clocks), and the idea that the tape register is constantly readable as a shifter is a bit of a guess, though Hewson's Southern Belle-style use of it implies it is a 10-bit register with an 8-bit window, just not necessarily that the 8 bits you read and write aren't aliased somewhere. Supposing they added an extra latch whereby the 8 bits are copied somewhere else statically upon a data full interrupt in order to ease CPU timing requirements, none of this will work.

User avatar
1024MAK
Posts: 6799
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...

Re: Turbo Cassette

Postby 1024MAK » Fri Apr 15, 2016 10:45 pm

The Acorn service manual for the BBC/Master Machines says this:-
service manual wrote:3.5 Cassette + RS423 + serial processor

For both the cassette and RS423 interfaces, a 6850 asynchronous communications interface adaptor (ACIA) (IC4) is used to buffer and serialise or deserialise the data. The serial processor (IC7), specifically designed for the BBC Microcomputer, contains two programmable baud rate generators, a cassette data/clock separator, switching to select either RS423 or cassette operations and also a circuit to synthesise a sinewave to be fed out to the cassette recorder. IC42 divides the 16 MHz clock signal by 13 (1.23 MHz) and this signal is divided further (by 1024) within the serial processor to produce the 1200 Hz cassette signal. Automatic motor control of an audio cassette recorder is achieved by using a small relay driven by a transistor (Q3) from the serial processor. The signal coming from the cassette recorder is buffered, filtered and shaped by a three stage amplifier (IC35). The RS423 data in and data out signals and the request to send output (RTS) and clear to send input (CTS) signals are interfaced by ICs 74 and 75 which translate between TTL and standard RS423/232 signal levels (+5V and -5V). The control register, which is memory-mapped at &FE10, specifies the frequencies for the transmit clock (bits 0-2) and the receive clock (bits 3-5) used by the 6850 ( IC4). The switching between the cassette and RS423 inputs and outputs is also determined by the control register (bit 6), and so is the motor control (bit7). R75 and C28 provide the necessary timing elements for delay between receiving the high tone run-in signal and asserting the data carrier detect signal to the ACIA. The value of resistor needed is affected by the output impedance of that pin on the serial. processor which has been subject to a certain amount of variation. Thus the value of R75 has changed through the evolution of the circuit.


For more information on the 6850 search online for the datasheet.

The internal circuitry for the ULA in the Elk, presumably is designed to replicate most of this behaviour.

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

ThomasHarte
Posts: 367
Joined: Sat Dec 23, 2000 5:56 pm

Re: Turbo Cassette

Postby ThomasHarte » Mon Apr 18, 2016 1:47 pm

1024MAK wrote:The internal circuitry for the ULA in the Elk, presumably is designed to replicate most of this behaviour.


It's definitely a single 10-bit shift register, the source of the clock being the only distinction between input and output; at the minute I'm not aware of any evidence either way on whether it latches. There's no reason to believe it's attempting to duplicate the ACIA in any more rigorous sense than that the video logic is attempting to duplicate the CRTC.

Evidence is the same as always cited:
  • the Players games never place the tape hardware into output mode, yet will fail to function if the "send data empty" interrupt (the real one, ignoring EAUG documentation errors) has not been set while data was loading; and
  • the two Hewson train simulators — Southern Belle and Northern Star — configure the hardware into output mode and write a byte with what looks like a start/stop pair in it in order to get something of a programmatic interrupt timer, catching "receive data full" (despite being in output mode).
So in one very special but real-world contemporary case, the Electron's tape hardware is even subbing for the absent 6522(s).

If it latches then, assuming a 5% tolerance in baud, I can't see you don't much more than maybe a couple of extra bits per byte. If it doesn't then the near-to-2400 bits per second (versus 960 normally) should probably be doable. So that's the difference between a 25% increase and a 150% increase.

(for the record, from the Hewson titles I have in the past confirmed the same clock divider as a BBC though — 1664 2Mhz cycles between bits)

jdavis6809
Posts: 13
Joined: Sun Jan 31, 2016 12:19 pm

Re: Turbo Cassette

Postby jdavis6809 » Thu Jul 21, 2016 6:35 am

Hello,

From the Advanced User Guide

20.6.1 Counter Divide Select Bits (CR0 and CR1)

These bits determine the divide ratios used in both the
transmitter and receiver sections of the ACIA. Additionally,
these bits provide a master reset which initialises the
transmitter, receiver and status register. The clock division rate
is normally set to 64 whilst the RS423 system is in operation.

The cassette system selects between 300 and 1200 baud using
this division ratio.

The serial ULA is always set to 300 baud for
cassette, so

Division by 64 actually generates 300 baud.

Division by 16 makes it 4 times faster so 1200 baud is generated.

Division by 1 would make it a further 16 times faster, ie 19200 baud but
the cassette will not operate at this speed.

CR1 CR0 Function

0 0 divide by 1
0 1 divide by 16
1 0 divide by 64
1 1 Master reset

The way to test this is load a file normal baud 1200 then set baud to 19200 then save file to mp3 player then play file back via mp3 player

not sure that the cassette input circuit op amp is bandwidth limited ?

john

User avatar
8bitkick
Posts: 68
Joined: Thu Aug 11, 2016 4:45 pm
Location: California
Contact:

Re: Turbo Cassette

Postby 8bitkick » Sat Oct 07, 2017 11:22 pm

ThomasHarte wrote:Oh, ouch, something like 1264 baud is the maximum? That's a very thin tolerance.


So, I think I've managed to get 1600 baud ... 0 to Arcadians in about 170 seconds :) It uses 1600Hz base frequency, carrier tone sections reduced a bit too, nothing fancy otherwise. 1620 is the ragged edge for my Electron.

This was using JS to create a 44.1KHz audio conversion from UEF. The conversion is done in browser

Acorn Electron Arcadians cassette audio @ 1600 baud (loads OK for me!)

https://s3-us-west-1.amazonaws.com/8bitkick/PlayUEF/PlayUEF.html?BAUD=1600

I am very curious... if the Acorn Electron with the right FXs could handle 19200 given this cleaner audio source? Has anyone done a little assembler pre-loader that could ready the machine for the onslaught? See below... and get dogs out of the room. :twisted:

Acorn Electron cassette audio @ 19200 baud (no chance?)

https://s3-us-west-1.amazonaws.com/8bitkick/PlayUEF/PlayUEF.html?BAUD=19200

You can edit the BAUD query for custom rates.

If using standard OS cassette FS at higher baud is not possible, a stream loader which can make use of the better quality / predictable timing of WAV audio...?
Last edited by 8bitkick on Sat Oct 28, 2017 3:53 am, edited 2 times in total.

paulb
Posts: 784
Joined: Mon Jan 20, 2014 9:02 pm

Re: Turbo Cassette

Postby paulb » Mon Oct 09, 2017 9:03 pm


User avatar
davidb
Posts: 1901
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Turbo Cassette

Postby davidb » Sat Oct 28, 2017 12:01 pm

I'll just add these two threads to the list since they may provide clues to improving loading performance:

User avatar
davidb
Posts: 1901
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Turbo Cassette

Postby davidb » Sat Oct 28, 2017 3:37 pm

8bitkick wrote:So, I think I've managed to get 1600 baud ... 0 to Arcadians in about 170 seconds :) It uses 1600Hz base frequency, carrier tone sections reduced a bit too, nothing fancy otherwise. 1620 is the ragged edge for my Electron.

You should be able to reduce the carrier tone sections down to around 60 bits worth (120 cycles of 2400 Hz) to be conservative.

8bitkick wrote:I am very curious... if the Acorn Electron with the right FXs could handle 19200 given this cleaner audio source? Has anyone done a little assembler pre-loader that could ready the machine for the onslaught? See below... and get dogs out of the room. :twisted:

My understanding of this interpretation of the cassette I/O is that the counter gets reset when it sees an edge (zero crossing?) and causes 1 or 0 bits to be pushed into the shift register if the counter is reset within certain ranges (above 240 for 1 bits, below 168 for 0 bits). I wonder if, by forcing the counter to start at a lower value you could increase the frequency of edges/crossings it can detect. Maybe it's not possible to play with the counter like this.

8bitkick wrote:If using standard OS cassette FS at higher baud is not possible, a stream loader which can make use of the better quality / predictable timing of WAV audio...?

If you can guarantee that bits are delivered correctly and don't need the overhead of the file system then you can dispense with the block headers. This saves a small amount of metadata from having to be transmitted.

Commie_User
Posts: 916
Joined: Wed Jan 27, 2016 12:50 am

Re: Turbo Cassette

Postby Commie_User » Sat Oct 28, 2017 11:13 pm

For reference, this was in ELECTRON USER. Hobbit seemed to have the issue down pat virtually as soon as the Electron was out. Who knows if there's an old one out there on Ebay anytime soon.

This surely rams in the data as fast as the Elk can handle it.

speedy.jpg

User avatar
davidb
Posts: 1901
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Turbo Cassette

Postby davidb » Sun Oct 29, 2017 12:05 am

I'm not sure if it was ever available for the Electron. It used a different drive that apparently used microcassettes, according to the brief review in Acorn User (see this page for the PDF).

The nascom.info site says that it interfaced to the Nascom's PIO port. Does anyone know which port it used on the BBC Micro?

User avatar
davidb
Posts: 1901
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Turbo Cassette

Postby davidb » Sun Oct 29, 2017 12:16 am

My memory was jogged into recalling Turbocon.

User avatar
8bitkick
Posts: 68
Joined: Thu Aug 11, 2016 4:45 pm
Location: California
Contact:

Re: Turbo Cassette

Postby 8bitkick » Sun Oct 29, 2017 1:12 am

davidb wrote:You should be able to reduce the carrier tone sections down to around 60 bits worth (120 cycles of 2400 Hz) to be conservative.


Thanks for the tip! This has shaved off 10+ seconds for Arcadians. My record is now 157 seconds! =D>

(1570 Hz base frequency... seems like my Elk doesn't like 1600 any more).

davidb wrote:My understanding of this interpretation of the cassette I/O is that the counter gets reset when it sees an edge (zero crossing?) and causes 1 or 0 bits to be pushed into the shift register if the counter is reset within certain ranges (above 240 for 1 bits, below 168 for 0 bits). I wonder if, by forcing the counter to start at a lower value you could increase the frequency of edges/crossings it can detect. Maybe it's not possible to play with the counter like this.


I will dig into this... I saw some warnings in those docs about odd behavior if the counter isn't reset properly...

davidb wrote:If you can guarantee that bits are delivered correctly and don't need the overhead of the file system then you can dispense with the block headers. This saves a small amount of metadata from having to be transmitted.


From MartinB's comments on UPURS experience this might not be easy to do without breaking compatibility with the UEF archive (i.e. finding a place in memory to hide the loader that game won't want to overwrite #-o )

User avatar
davidb
Posts: 1901
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Turbo Cassette

Postby davidb » Sun Oct 29, 2017 12:17 pm

8bitkick wrote:Thanks for the tip! This has shaved off 10+ seconds for Arcadians. My record is now 157 seconds! =D>

:D

8bitkick wrote:
davidb wrote:My understanding of this interpretation of the cassette I/O is that the counter gets reset when it sees an edge (zero crossing?) and causes 1 or 0 bits to be pushed into the shift register if the counter is reset within certain ranges (above 240 for 1 bits, below 168 for 0 bits). I wonder if, by forcing the counter to start at a lower value you could increase the frequency of edges/crossings it can detect. Maybe it's not possible to play with the counter like this.


I will dig into this... I saw some warnings in those docs about odd behavior if the counter isn't reset properly...

It might be difficult to get anything working but maybe someone can think of something to try.

8bitkick wrote:From MartinB's comments on UPURS experience this might not be easy to do without breaking compatibility with the UEF archive (i.e. finding a place in memory to hide the loader that game won't want to overwrite #-o )

I'll add some points about that to the Electron Game Server thread as they will be more about your particular solution than generic turbo loading.

User avatar
BigEd
Posts: 1500
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Turbo Cassette

Postby BigEd » Sun Oct 29, 2017 1:08 pm

Have you tried arranging for a shorter than normal stop bit? It could only gain 5% so perhaps isn't worth it. (If the stop bit is detected half way through the bit time, you can possibly follow it with the start bit transition earlier than you normally would.)

I have no idea how you'd arrange to do it, mind.

Commie_User
Posts: 916
Joined: Wed Jan 27, 2016 12:50 am

Re: Turbo Cassette

Postby Commie_User » Mon Oct 30, 2017 12:11 am

Is there some way to port the tape data to digital storage via the Electron serial, so you can flood it back in through a modem socket or something?

On the Commodore, we had something called MTAP and PTAP. The chain was Datasette to Commodore 64 to PC. The last two connections are the Commodore's serial to a PC parallel port. You got a first generation digital copy of the tape itself to a TAP file on the PC, which could be piped back to tape in the opposite direction, loaded into an emulator or otherwise tinkered about with.


Return to “software: other”

Who is online

Users browsing this forum: No registered users and 2 guests