Tapuino, the $20 C64 Tape Emulator

[demolition]

Regarding SD card speeds, I found that slower cards (lower Class) are often faster when used with Arduino. Reason is that the Class specifies the performance in the highest speed mode while the Arduino board accesses the card through a much slower legacy mode. So what matters is the speed of the legacy mode and that is not reflected by looking at the Class rating.

So if you have a different card with a different brand and/or different Class, it may work better.

I don't know the buffer size used for writing in Tapuino, but the larger the better speed you can achieve and if running off a Nano, there is not room for much buffers. Single byte writes are really slow due to massive overhead. I did a few SD write benchmarks on an Arduino a little while back and found that I needed 8k or so write buffers to be able to keep up with the fastest tape pulses I could find, so effectively using all of the memory in a Nano.

 

[sweetlilmre]

Hi, the Nano has 2K RAM, 256 bytes of which are dedicated to the SD card write / read buffer in a 128 byte back to back configuration. I'm looking at moving this firmware to a STM32 platform, only 20k of RAM but that would leave a lot more headroom.

-(e)

 

[sweetlilmre]

Well this is interesting...

I was reading about the Manusoft Princess SD2IEC device which also has TAP dumping support.
One of the links on the page is to an archive of the source code: http://www.manosoft.it/wp-content/uploads/2015/01/sd2iec-0.10.4.0.rar

Turns out that their tape grabbing code (tapget.c) appears to be a near direct copy of the Tapuino code (even variable names are the same).
I've contacted the author to ask them to include the MIT license and my copyright.
I'm happy for them to use this (that is why I licensed the code under MIT) but I would hope that the code could remain unrestricted.
In this way we can both benefit from any improvements to the codebase (I cannot pull GPL code into my code).

Why am I bothering you about this? I'd like to state my case plainly and upfront so that there is a clear and hopefully unambiguous record.

-(e)

 

[sweetlilmre]

A small update on this:
The author has replied to me and will be adding the appropriate licence. He (I'm assuming) seems like a decent bloke and willing to come to the party.
Hopefully this is a win for all of us going forward.

Thanks
-(e)

 

[c64new]

Well this is interesting...

I was reading about the Manusoft Princess SD2IEC device which also has TAP dumping support.
One of the links on the page is to an archive of the source code: http://www.manosoft.it/wp-content/uploads/2015/01/sd2iec-0.10.4.0.rar

Turns out that their tape grabbing code (tapget.c) appears to be a near direct copy of the Tapuino code (even variable names are the same).
I've contacted the author to ask them to include the MIT license and my copyright.
I'm happy for them to use this (that is why I licensed the code under MIT) but I would hope that the code could remain unrestricted.
In this way we can both benefit from any improvements to the codebase (I cannot pull GPL code into my code).

Why am I bothering you about this? I'd like to state my case plainly and upfront so that there is a clear and hopefully unambiguous record.

-(e)

This is an episode that makes me not happy to be in this country.
I hope that everything is in good faith, but Manosoft sells and not Sweetlilmre.
This does more honor to Peter.
Unfortunately dear Manosoft (apart from the copied code) is the idea that was taken!
And this is not nice. Just ask the inventor of Tapuino prior to sale.
I know some Manosoft follows this thread and bought also an Tapuino, so, for me, the doubt remain ...
And it's not nice to say about the internet that your project is better than the Tapuino, because here we work for free and we can improve gradually, without compensation of money.
Let's see if your project will 'open' as that of Sweetlilmre.
Sincerely
PS: all this resentment is because too many of us have wasted so much time to develop and improve the Tapuino! And we hope that Peter, for this not leave the project.

 

[sweetlilmre]

Hi.

I have been in contact with the author and he has been very happy to sort this out. So thanks for your support, but I don't feel that there is anything to worry about from now on.


-(e)

 

[Staple_nutz]

Hi all,

First of all thank you Sweetlilmre and all that have contributed to this incredible project. After recently blowing the dust off me C64's again I decided I needed a modern option for loading my games. As my poor old tapes and disks being 3 decades old are rapidly deteriorating.

I decided on building the Tapuino not so much because of its price point, but more because of its DIY feel and the sense of community the goes with this little gem (I have read every page of this thread to see how its progressed). To hear someone who has taken Tapuino code for commercial use without prior notification or request from the author is a little disappointing, I hope it all works out as you say.

Anyhow I'll be continuing to follow all posts and progress. I'm not sure I'm in a position to really contribute much toward the progress of the project, unless you need someone to test their AR Mk6 cart with real hardware and not the emulator's. By all means ask me if there is anything you'd like tested.

Loving the Tapuino

 

[Buleste]

Class of card was the key to recording. Class 4 Kingston was too slow. Thanks everyone for your help.

 

[c64new]

Class 10 is ok

 

[caiusfabricius]

Maybe I found a little bug with some .TAP where counter stops to working but file is successfully loaded and game starts (The last Ninja II is an example).
I'm also wondering if something can be done in the future with multigames .TAP.I think we could study the source of VICE emulator and see how developer implemented the counter emulation.

 

[sweetlilmre]

I already know how to do this, but not how to implement it many games will have "space" at the end of the .TAP and so will never reach 100%

Sent from my Nexus 5X using Tapatalk

 

[caiusfabricius]

I already know how to do this, but not how to implement it many games will have "space" at the end of the .TAP and so will never reach 100%

Sent from my Nexus 5X using Tapatalk

I think working with Arduino NANO hardware is pretty limiting, maybe we should move to something more expandable and flexible.

 

[devrim]

Hoo i read the whole thread in 2 hours. today i build my own one on a breadboard. it works fine.
but some questions.

i used a 2004 lcd, is it possible to show the current directory in the 2 lines which are clear?
the sketch is made for 1602. i translated the mem to german language and used 20 lines per space.
now the other 2 lines are clear. i can use a mega too, if the sketch will not fit in memory.

and another question is, if we could use a rotary encoder? i have no much electric items at home.
for example i used a npn instead of the 4n25

 

[devrim]

nobody with a rotary encoder?

 

[sweetlilmre]

Hi sorry I haven't answered this earlier it's been year end madness. An encoder is a great input mechanism for the Tapuino and something I was originally planning on. I even have a blog entry on a nice state machine implementation for encoders. I've seen your issue request on GitHub and I'll try to get some time to look at this. In terms of the translation, if you can make this 16 chars compatible I will include it in the build. 20x4 displays have a weird layout and were too large (in my opinion) when I started this. Also cheap boards only really featured the 328. With very cheap ARM boards now available, this would be the next logical step.

Sent from my Nexus 5X using Tapatalk

 

[albepancio]

is it possible that bubble bubble loads me up to 45% and then the game perfectly departs?
I have created the tap using a file d64 and then frezz with action replay 7 and recorded with super I upset

 

[stephenfalken]

I have created the tap using a file d64 and then frezz with action replay 7 and recorded with super I upset

I have not yet managed to get a successful SuperTurbo action replay save to work on the Tapuino. However, the standard Turbo save mode works great and isn't much slower so I would suggest using that one.

Regards

 

[albepancio]

the file works fine in super turbo,
this is a video of another game saved in superturbo .
I used a file d.64 and
I convert a file with vice, using action replay.






This is pit stop 2 converted from d64 to T64 super turbo.


<span id="result_box" class="" lang="en"><span class="hps">

 

[CMPunk]

That's very inspiring, I'm now motivated to build one of my own, thanks a lot!

the file works fine in super turbo,
this is a video of another game saved in superturbo .
I used a file and
I convert a file with vice, using action replay.


is pit stop 2 converted from d64 to T64 super turbo.


<span id="result_box" class="" lang="en"><span class="hps">

 

[albepancio]

pitstopmod because I set the speed limit to 239 for all machines : )

this is the conversion from d64 to super tap I upset using vice