Tapuino, the $20 C64 Tape Emulator

  • Thread starter Thread starter sweetlilmre
  • Start date Start date
  • Replies Replies 1059
  • Views Views 299319
Hey dude. Just so you know I haven't lost interest in the project, I've just been busy with other stuff that has taken more time than I anticipated!

I will get to work with more testing this week hopefully. I'm no expert at Turrican but I can get at least as far as the level where further loading is done from tape.

Will let you know how I get on as soon as!

Regards
 
One turn of the counter should always equate to the same length of tape..

but are you sure?.. the counter is connected to the right capstan with a fixed transmission ratio, once the right reel has a lot of tape on it, because we're at the end of the tape, one turn of it will be wound on a circumference that is far more than the one you have when the reel is empty. Moreover, if the counter takes far more time to switch from one number to the next (and this happens at the end of the tape), given the tape speed is fixed to 5,5 cm/s, I think that in front of the reading head you will see more length of tape passing.. am I incorrect? And this effect depends on how big is the circumference of the tape wound on the reel that in turn depends on the number on the counter and the tape thickness

All tapes are indeed not created equal, I have 2 C90 tapes that come in at 615 and 630 respectively.

Yes, this because the lenght is always approximate, each side of a C90 is usually more than 45mins but by how much depends on the vendor

The thickness of the tapes should generally be the same for the same length tapes Wikipedia: "The C46 and C60 lengths typically are 15–16 um thick, but C90s are 10–11 µm and C120s are just 9 µm thick", so this is not really an issue.
Time ago I was running after *exactly* the same thing you're doing. From the tests you will carry out you will see yourself this is not correct.
Trying to write a graph of the law "speed of counter"/"time" to determine coefficients you will notice that different brands of the same cassette type have different ratios. This is due to the production costs. A thicker tape is of better quality, resists very well to the traction but costs more, low quality tapes tends to have the same very thin tape also on low duration cassettes to save money. A very slight difference in the coefficient will lead to misalignment of the virtual vs real counter of two three turns even after just 30-40 turns.

So, the initial request was for multi-load Turrican where the player is asked to "Rewind to position 30" or such. For this we'd need to have something that mapped fairly accurately to the physical behaviour of the counter.
Is it possible to point me to this version of .TAP? The vast majority of tape games I came across were saying to zero the counter and then rewind to zero or to rewind to the beginning of the tape. I never found a game that was asking to rewind to a specific counter position without giving you any visual clue on where the point it was, also because all the C2N are different, you won't find two different models with the same counter ratio, Commodore ones are different from compantibles, and 1530 is different from 1531, also 1530 has two different kind of counters (the one with white numbers on black drums and the one with white numbers on black drums) then there are magnum ones, unbranded ones, etc.. If they did this with Turrican I think it was very stupid.

On the other hand there is another thing that is missing. In some games user is asked to stop the tape at the end of the loading. In your case this is not possible since if this game is part of a long TAP file SENSE will be kept shorted to ground at all times even if motor goes off at the end of program loading. My suggestion is to add N/C button in series with SENSE line to be sued just in these cases.

I checked also the memory usage of the program and it looks fairly high (at least according to Tapuino IDE) I recompiled the whole thing on Atmel studio and I could save some 6Kb that could be reinvested. The issue is mainly with fatFs version used. If you're not using all the functions you might decide to switch to a lighter version of FF.

By the way, I built one Tapuino and it works good
 
Last edited:
One turn of the counter should always equate to the same length of tape..

but are you sure?.. the counter is connected to the right capstan with a fixed transmission ratio, once the right reel has a lot of tape on it, because we're at the end of the tape, one turn of it will be wound on a circumference that is far more than the one you have when the reel is empty. Moreover, if the counter takes far more time to switch from one number to the next (and this happens at the end of the tape), given the tape speed is fixed to 5,5 cm/s, I think that in front of the reading head you will see more length of tape passing.. am I incorrect? And this effect depends on how big is the circumference of the tape wound on the reel that in turn depends on the number on the counter and the tape thickness

The counter is connected to the take-up reel (right reel), not capstan, at least in my Datasette. As the take-up reel is driven by the motor using a slip / friction arrangement, the reel will maintain tension on the tape. As the tape moves at a fixed rate of around 4.75cm/s then the rotational speed of the take-up reel will slow as more tape is wound onto it and the diameter of the reel increases. And so the counter will slow and the length of tape per count will be maintained. At least as far as I understand it.
Certainly the amount of tape passing the read head per second is constant. This site gives a great explanation: http://www.physicsforums.com/showthread.php?t=150935

All tapes are indeed not created equal, I have 2 C90 tapes that come in at 615 and 630 respectively.

Yes, this because the lenght is always approximate, each side of a C90 is usually more than 45mins but by how much depends on the vendor

The thickness of the tapes should generally be the same for the same length tapes Wikipedia: "The C46 and C60 lengths typically are 15–16 um thick, but C90s are 10–11 µm and C120s are just 9 µm thick", so this is not really an issue.
Time ago I was running after *exactly* the same thing you're doing. From the tests you will carry out you will see yourself this is not correct.
Trying to write a graph of the law "speed of counter"/"time" to determine coefficients you will notice that different brands of the same cassette type have different ratios. This is due to the production costs. A thicker tape is of better quality, resists very well to the traction but costs more, low quality tapes tends to have the same very thin tape also on low duration cassettes to save money. A very slight difference in the coefficient will lead to misalignment of the virtual vs real counter of two three turns even after just 30-40 turns.

Yes there doesn't seem to be consistency. I was wondering about tape 'quality' with the Type I II, IV etc. tapes, thanks for bringing that up.

So, the initial request was for multi-load Turrican where the player is asked to "Rewind to position 30" or such. For this we'd need to have something that mapped fairly accurately to the physical behaviour of the counter.
Is it possible to point me to this version of .TAP? The vast majority of tape games I came across were saying to zero the counter and then rewind to zero or to rewind to the beginning of the tape. I never found a game that was asking to rewind to a specific counter position without giving you any visual clue on where the point it was, also because all the C2N are different, you won't find two different models with the same counter ratio, Commodore ones are different from compantibles, and 1530 is different from 1531, also 1530 has two different kind of counters (the one with white numbers on black drums and the one with white numbers on black drums) then there are magnum ones, unbranded ones, etc.. If they did this with Turrican I think it was very stupid.

You are correct, the game asks to reset the counter and rewind to position 986. I got the incorrect idea about how this worked.

On the other hand there is another thing that is missing. In some games user is asked to stop the tape at the end of the loading. In your case this is not possible since if this game is part of a long TAP file SENSE will be kept shorted to ground at all times even if motor goes off at the end of program loading. My suggestion is to add N/C button in series with SENSE line to be sued just in these cases.
Sounds like a good idea though I'd probably implement this in the firmware. I need to rethink the playback interface anyway so adding this kind of functionality is a good match for that.
I checked also the memory usage of the program and it looks fairly high (at least according to Tapuino IDE) I recompiled the whole thing on Atmel studio and I could save some 6Kb that could be reinvested. The issue is mainly with fatFs version used. If you're not using all the functions you might decide to switch to a lighter version of FF.
Good news! What did you remove from the library, I didn't see too much that could be removed from FatFs because of the need for the write support?
Or was it specifically the change to Atmel Studio? I've been keen to change over myself, but have been worried about raising the barrier to entry (Arduino IDE is so simple) or having to provide binaries.
Do you have a patch? If so, you can send me a pull-request on Github. Otherwise just detail any changes in the thread :)

By the way, I built one Tapuino and it works good

WOOHOOOO! Excellent stuff :) So that is another one and my mate at work is going to build one this week hopefully.
I have a new bus design and a mux board idea for the next hardware 'rev'.

-(e)
 
FYI:

I tested the Vice counter with Turrican last night and it seems to work, in that the "zero and rewind to 986" allows me to load a level again.
I'll have a further look into it tonight.

-(e)
 
Curiouser and curiouser....

turrican-rewind-30.png
 
That's the message on Turrican isn't it?

What is curious about it mate?

I was only getting the "Reset and rewind to 986" message before (think it might be the difference between continuing or not at the end of a game).
There has been a lot of doubt about how this expected behaviour would work with different tape decks, but it would seem that it must! :)

This is fairly good news as Vice seems to accurately (enough) display counter values that work with Turrican and so seems to have a fairly realistically modelled counter.
 
sweetlilmre excellent work!!!!

I have successfully built another Tapuino, and is working. Only tested loading a game, but it works great.
Waiting for the new hardware rev to connect datassette.

I need to look for a suitable box to put all together.

I will have a look if I can help in hardware because I'm electronic engineer.
 

Attachments

  • DSC03231c.jpg
    DSC03231c.jpg
    193.9 KB · Views: 7
I just updated my Tapuino to the current code to make sure im up to date.

Tried saving with SuperTurbo (Action Replay 6), but it still won't load the game again.

Saving from Tapuino to Datasette still working, but Datasette to Tapuino still doesn't save anything (im guessing that is still the expected behaviour, however).

Is there any other testing I can help with?

Regards
 
sweetlilmre excellent work!!!!

I have successfully built another Tapuino, and is working. Only tested loading a game, but it works great.
Waiting for the new hardware rev to connect datassette.

I need to look for a suitable box to put all together.

I will have a look if I can help in hardware because I'm electronic engineer.

Brilliant! New rev coming this week I hope :)
 
I just updated my Tapuino to the current code to make sure im up to date.

Tried saving with SuperTurbo (Action Replay 6), but it still won't load the game again.

Saving from Tapuino to Datasette still working, but Datasette to Tapuino still doesn't save anything (im guessing that is still the expected behaviour, however).

Is there any other testing I can help with?

Regards
Hmm was sure that super turbo would work with the much faster sampling. I hope I didn't forget to push any changes... Can you send me a super turbo you saved to the Tapuino?
 
I get the feeling that it isn't an issue with the Tapuino recording. Surely the Datasette always records at the same speed, regardless of what type of data/fast loader is being sent from the C64? So I would guess that if the Tapuino can record, it should record anything that is sent? However I could be way off and incorrect with that lol.

I will try recording a supertubo to Datasette and make sure that works first before I accuse the Tapuino of being at fault!

Regards
 
I get the feeling that it isn't an issue with the Tapuino recording. Surely the Datasette always records at the same speed, regardless of what type of data/fast loader is being sent from the C64? So I would guess that if the Tapuino can record, it should record anything that is sent? However I could be way off and incorrect with that lol.

I will try recording a supertubo to Datasette and make sure that works first before I accuse the Tapuino of being at fault!

Regards

Yeah that may be an issue, from the AR manual:
SUPERTURBO - Saves at 8-10 times standard speed - data is packed much more and backups load in around 2 minutes. This speed requires a tape deck in good condition and high quality, short length tape for reliable loading. Some tape decks cannot load at this speed.

As far as Tapuino issue, the sample rate could be a problem, though shouldn't be after I jacked it up.
 
Last edited:
Tapuino R2 layout with a better bus layout and control lines for the mux daughterboard.
Should be built tomorrow and then hopefully the daughter board next for a proper test.

tapuino-main-r2.jpg

Sorry for the slowness of updates, life is still somewhat hectic.
-(e)
 
Last edited:
Excellent dude! Look forward to seeing it.

I will be going along to Play Expo on the 11th so will hopefully bump into some other Amibayers. I will take my Tapuino prototype with me (someone is bound to take a C64 lol) and try and generate some more interest in the project! Even without further development it is an amazing device and I don't think enough people know they can build one so cheaply! I still can't thank you enough for your effort in building it!

Regards
 
Excellent dude! Look forward to seeing it.

I will be going along to Play Expo on the 11th so will hopefully bump into some other Amibayers. I will take my Tapuino prototype with me (someone is bound to take a C64 lol) and try and generate some more interest in the project! Even without further development it is an amazing device and I don't think enough people know they can build one so cheaply! I still can't thank you enough for your effort in building it!

Regards

Awesome stuff, and thanks for your testing, it wouldn't be nearly as functional without it!

I'm so jealous of all the expo's etc. you have in the UK. There is literally nothing in SA :(.
I'm going to try and coincide a trip next year for Retro Replay or something like that.
I have to see what's happening beginning of Feb next year as I will definitely be over then!

-(e)
 
erk... disregard that last design, it was:
  1. bad
  2. incorrect

:)

This should be correct and much more elegant (also about 3 fewer jumpers):

tapuino-mux-board-r2.png
 
Back
Top Bottom