TAPClean Front End packages were updated with the latest release of TAPClean, 0.36.
TAPClean Front End main window
Download links for Windows and Linux are available here.
Also, the Linux 64-bit binary of TAPClean 0.36 was made available on sourceforge.net, here.
Enjoy!
Yesterday I had some time to also make the TAPClean code migration to Git in sourceforge.net so I thought it’d be interesting to actually try creating release 0.36 off the Git repository. It all went so smoothly that I think I will use the Git repository for all future work 🙂
The latest Windows/DOS binaries are available here.
Should you wish to clone the repo and build TAPClean by yourself, you can use the following Git URL: git://git.code.sf.net/p/tapclean/gitcode
I will release an update to TAPClean Front End in the next few days to support the latest changes in TAPClean version 0.36. If you feel comfortable doing manual changes to your TCFE setup, along with updating the TAPClean executable, you’ll have to update your scanners.txt file contents as per below.
Instead of:
4:chr:CHR
Have a line that reads:
4:megasave:Mega-Save (was CHR)
And, instead of:
2:oceannew1t1:Ocean New T1 2:oceannew1t2:Ocean New T2 2:oceannew2:Ocean New 2 0:oceannew3:Ocean New 3 2:oceannew4:Ocean New 4
Have:
2:oceannew1:Ocean New F1 2:oceannew2:Ocean New F2 0:oceannew3:Ocean New F3 2:oceannew4:Ocean New F4
The two changes that are necessary to support version 0.36 of TAPClean are, in fact:
I’ve updated my disk version of Barbarian II to 1.1, which includes:
The third point had quite hilarious consequences. I guess I was in competitive mode when I tested my first version, hence trying not to get hurt, so I missed the fact that sprites used in certain death sequences were always overwritten with the ones for the female character. As example, at level 1 if the purple dragon ate the male character’s head, his collapsing body would have been the one of the female character!
Barbarian II IFFL version by Luigi Di Fraia
The corrected and improved version is available here. I shall copy it to a real disk tomorrow and play it on my C64 🙂
As support for CVS commits is going to be discontinued in late November on sourceforge.net, I decided to convert the code repository to Subversion, SVN for short.
Next week I will be double checking how things work with SVN tools/integration. The choice of SVN over Git was mainly dictated by the fact the “revisioning” paradigm used in SVN is closer to CVS than Git’s. However, I also have the option to convert the code repository to a Git repo, which I might end up doing eventually as it would make the migration to e.g. GitHub quite simple in future.
Finally, I might decide to have an early release, 0.36, ahead of the final migration. Stay tuned!
I’ve already briefly discussed the fact that the “Palace” tape loader does not use timers for discriminating bit 0 and bit 1 pulses. What I wanted to do was adding some more information around the tape for “Barbarian II”.
Side A loads fine as it was encoded using John Twiddy’s “Cyberload”, but side B has been quite problematic in my experience. One can certainly improve things by expanding silence gaps between files, making pilot trains longer, etc., but this odd bugger seems to be still quite temperamental, which adds to the frustration due to the game being quite difficult to play.
Having improved TAPClean to cope with extracting details from “Palace” loader files, I decided to put together a disk version of it. No trainers/cheats or the alike: I just wanted a truthful port of the original game from tape to disk that would load without being temperamental.
As you might have noticed I’ve been quite quiet recently and the reason is that I was putting together an IFFL system based on Covert-Bitops’s rant on the subject.
Lasse left it to users to add support for packed files, as an exercise, so that’s what I did. Not just that. I’ve also added a 1-bit transfer alternative and a few extra goodies that allowed me to come up with a surprisingly low memory footprint IFFL disk loader.
I am therefore happy to share my IFFL version of “Barbarian II” for the 1541 family of drives. Grab a copy here and enjoy the game without trainers!
Barbarian II IFFL version by Luigi Di Fraia
As part of the work to assemble this version I also passed the loading picture through my conversion tool that rearranges bitmap, video and color RAM so that the output file compresses better (and therefore loads faster, yay!). Other than that, I’ve been careful not to change anything that did not require changing 🙂
In order to make a version of Rubicon that runs off two disks, I had to remove built-in protections designed to make things go horribly wrong unless the game is specifically loaded from tape and by its original loader.
Rubicon load picture
Rubicon title screen
$dc0c is set to 0xd0 within the “Cyberload F3” loader (after a sync byte is read in from tape):
*=$fa64 lda #$d0 sta $dc0c
When any level starts, if $dc0c is not 0xd0 then the play area is littered with spurious chars.
Disable protection: set $dc0d to 0xd0 as early as possible and certainly before Level 1 starts.
At Level 1 $2f95 is set to the value at $01 as per below:
*=$1765 iny ; Y=1 now lda ($07),y ; $07/$08 = 0x0000 sta $29f4,y
If the game is loaded from tape, when Level 1 starts the datasette play button is still pressed, hence bit 4 at $01 will be clear, so that $01 will hold 0x25. If the game is not loaded from tape, then $01 will hold 0x35, which enables unlimited energy for the green dragon, making it impossible to complete this level.
Disable protection: replace instruction at $1766 with “lda #$25”.
Before loading upper levels, $1507 is set to the value at $01 as per below:
*=$0b41 lda $fffa,x ; X=7 now sta $1500,x dex bpl $0b41
Again, when a value other than 0x25 is found there, the protection kicks in after the level is loaded, during the gameplay.
As example, at Level 2 the game crashes when the trap is about to be detected.
Disable protection: At $0b30 there’s some code to wait for the play button to be pressed on the C2N. This code can be removed for a disk version and the subsequent code can be shifted up to $0b30. The shifting leaves enough room to add the following code just after the above block:
*=$0b44 lda #$25 sta $1507 nop
When the game is over, the “Software” sprite bitmap is not reset to show that no parts were collected.
However, upon game over, the tape version of the game shows a message that requests rewinding to the beginning of Side B as per below:
ldx #$1b b0f54 lda $0f6f,x sta $cd19,x lda #$0f sta $d919,x dex bpl b0f54 lda $dc00 and #$10 bne *-5
After the game is transferred to disk, such message is not relevant any longer, and can be replaced with:
ldx #$3f lda #$00 sta $bfff,x dex bne *-4
The above code correctly re-initializes the sprite, ready for playing again from Level 1.
Also, at the beginning of Level 4 there’s some code that is supposed to set the overall “Software” sprite bitmap (so that it shows three parts were collected) as it happens at Level 2 and Level 3 (where the sprite is set for 1 and 2 parts respectively). However, the code is just not quite right:
ldx #$0b b2446 lda $1b30,x sta $c00f,x dex bne b2446
The side-effect of the above code is not visible as the sprite bitmap is already in a suitable state, unless a level skipper trainer was used to skip part of Level 3 before the third software upgrade was taken.
When a level skipper trainer is installed, the above code has to be changed to:
ldx #$1b b2446 lda $aaf5,x sta $bfff,x dex bne b2446
Finally, if a level skipper is used to skip from Level 4 to Level 5 before the last part of the software upgrade is taken, in Level 5 there’s no code that adds the missing part to the sprite bitmap. So the level skipper has to do the work when skipping part of Level 4:
ldx #$0b ; Complete the sw sprite bitmap at Level 4 before skipping to level 5 _sprcp lda $1b3b,x sta $c00f,x dex bne _sprcp
That’s all for now. Enjoy this release and don’t forget that it loads at ultra-fast speed if you disable true drive emulation in VICE 🙂
The ICO bubble seems to have become popular among crypto currency adopters in the last few months. We also went through some spectacular price action recently, with some crypto currencies losing 30%-50% of their value in a matter of days. Therefore, I thought to spend some time discussing the components that are being referenced in a number of online communities and the unnecessarily complicated paradigm some of them recommend.
Starting with MyEtherWallet: this has been my initial choice for a wallet to hold Ether. Part of the reason is that the Ether wallet application I ran once on my PC never managed to catch up with the public ledger, thus resulting in an unusable tool.
Also, MyEtherWallet is NOT an online wallet, plus the way it operates is very different from the way wallets work within conventional exchanges (such as Coinbase, Poloniex, Kraken, etc.). Let me expand on that and tell you why this is important.
Yes, MyEtherWallet happens to use Web technology (after all it is accessible as a Web page online) but it only requires the online infrastructure for transactions. In other words, you hold the private key of the wallet and nobody else holds it for you: If MyEtherWallet shuts down online services, you can use your keys in a different Ether wallet handler and you’re still in charge of your Ether and Erc20 tokens. Furthermore, and this is really important for transparency and fairness, when you transact Ether or Erc20 tokens with MyEtherWallet you are generating transactions on the Ether blockchain.
How is the above different from an online wallet available in conventional exchanges and why is it transparent and fair? Well, firstly with most other conventional online exchanges you do not own the private keys for your wallets: if you did you could, as example, transact outside of the exchange most of the time, thus avoiding the fees the exchange charges you, going with whoever else is cheaper at any given time or whoever has the best exchange ratio for the crypto currency couple you want to trade. Secondly, transactions within conventional exchanges do not generate blockchain transactions (you can verify this with a blockchain explorer, if in doubt): they use a pool of crypto currencies that the exchanges might have to acquire from the open market at some point. This means that if you buy e.g. a Bitcoin in a conventional online exchange, they don’t need to buy one on your behalf and you won’t need one to transact within the boundaries of the exchange itself. The only time the exchange allocates crypto currencies to users is when users transfer balances out, which generates a transaction on the blockchain: exchanges better have these currencies on the side line for when that happens or users will lose trust in them and avoid them.
Very much like fractional reserve banking, most conventional online exchanges know that not every account holder will withdraw their crypto currencies at the same time, so they only need to keep some on the side lines ready for when somebody transfers out. However, they have no obligation to have enough cryptos to cover the balance that all of its users hold with them.
Remember that crypto currency exchanges are NOT regulated by any financial authority (yet) and at times they wait to buy cryptos until these are cheap, so they also can sell them back to users for a profit: is it surprising that when prices fall and user’s buy demands raise exchanges cannot cope with that? It’s not just about volume: re-selling crypto currencies when their price is low is not convenient for exchanges, as that might mean selling at a net loss.
Essentially, their business model is along these lines: if they don’t annoy too many people they can stay afloat and make a profit with fees on transactions and reselling crypto currencies based on spread (and, possibly, at a premium). Part of such profits go towards ROI as they had to set up the exchange, recurring maintenance costs, etc.
Back to transparency and fairness, here’s my point: most conventional online exchanges can shut down without any notice and run away with the money because funding their wallets with fiat and participating in internal transactions are not recorded on the public ledger! They are not likely to run away as nobody wants to go through a class action, but remember it’s basically a trust relationship, with them working for profit. Things can also go wrong in case of hackers exploiting security vulnerabilities that might exist with some exchanges not so keen to roll-out updates and/or invest in security.
These are the two main reasons I personally do not trust exchanges and only use them for exchanging crypto currencies with other crypto currencies, based on price action. Once I am satisfied with the price action of the crypto currencies I hold there, I transfer them out to wallets for which I hold the private key. I then wait until the next price action to get back in the game.
Moving on to EtherDelta: this is currently my wallet and exchange of choice for Ether and Erc20 tokens that I have been investing during the early stages of the ICO mania. Much like MyEtherWallet, you own the private key of your wallet and you only need the online infrastructure for exchanging, depositing, and withdrawing Ether or ERC20 tokens. Also, unlike many conventional online exchanges, all transactions you make in EtherDelta, including moving funds from your wallet into the exchange account itself, generate transactions on the blockchain.
How do I know that EtherDelta provides me with a wallet that I am not forced to use just within their online exchange? Simple answer: I can use the private key that was generated when I created the EtherDelta profile in MyEtherWallet and transact from there.
When at the start of this post I mentioned an unnecessarily complicated paradigm I was referring to the fact that a number of crypto adopters suggest you always hold your Ether and Erc20 tokens in MyEtherWallet. They say you should only move them into EtherDelta to exchange them for other tokens or Ether, and finally move what you ended up with back into MyEtherWallet! This is not necessary and generates two extra transactions on the blockchain: the funding from your MyEtherWallet wallet to your EtherDelta wallet and the transfer out the other way around!
What you can do is to just create the EtherDelta wallet and keep your private key private. Any time you want to transact out of EtherDelta, such as funding an ICO, you open up your wallet in MyEtherWallet, using the mentioned private key, and transact there with your EtherDelta wallet address: in this way you can choose the amount of Gas to use, add additional data that certain ICOs require, etc.
What I encourage you doing is to NOT keep Ether and Erc20 tokens on the exchange: after your trading activities are over, simply deposit balances back into your EtherDelta wallet.
Let me state this once again: the EtherDelta wallet is fine for transacting outside of the exchange as long as you use it within MyEtherWallet to transact, which is where you have finer control over the details of transactions. What you cannot do is things like funding an ICO straight from your EtherDelta wallet within the exchange itself using the “transfer” option as you don’t seem to have fine control over the details of the transfer.
The reason this is possible is very simple: essentially a minimal wallet is a couple of keys, one private for authorizing transactions, and one public, an address for receiving/sending crypto currencies and tokens. The Ether wallets for which you hold the private key are all functionally identical once you activate them in MyEtherWallet.
Another reason for loading up your EtherDelta wallet in MyEtherWallet, and transacting from there, is that EtherDelta only shows three digits after the decimal dot for your balances. I am not sure whether this can be changed on the EtherDelta page or not, but if you want to see all decimals that you hold there, you are better off opening up the wallet in MyEtherWallet at present.
That’s it folks. Stay safe outta there with the ICO bubble reaching critical mass!
 | pawelriversedge on TAPClean Front End update… |
 | luigidifraia on TAPClean Front End update… |
 | pcollins on TAPClean Front End update… |
| luigidifraia on TAPClean 0.36 released |
| pcollins on TAPClean 0.36 released |
