As part of the ongoing update of my framework for USBhost-64 I rewrote USB-BASIC from scratch, thus getting to release 2.0 of it. Most commands have been reimplemented and tested successfully.
USB-BASIC 2.0: Commands
I am still looking for an elegant way to implement a few more in release 2.1 before flashing it to my EasyFlash cartridge. I think that will pretty much be it for USB-BASIC: the rest of the cool stuff will only progress for the assembly and C frameworks.
USB-BASIC 2.0, the latest BASIC interface to access USBhost-64, is much more focused on its compatibility with CBM BASIC, providing features found in standard LOAD and SAVE commands. In a nutshell, ULOAD “NAME” as example behaves pretty much like LOAD “NAME”,N,1 whether it’s issued in direct mode (at the READY prompt) or executed in a running BASIC program.
In order to demonstrate how BASIC programs can be made agnostic of the device they use, I could have used the load and save vectors at $0330/1 and $0332/3 respectively, so that LOAD and SAVE commands would be diverted to my own USB kernel when e.g. the device number is 16 or thereabout.
However, as I mentioned above, I chose to once again leverage my BASIC Interpreter extension framework and adapt the Commodore 64 disk version of “The Sword of Fargoal” to load using the new ULOAD command provided by USB-BASIC 2.0. Enjoy! :)
As I dive in and out of the BASIC interpreter and Kernel of the Commodore 64, I thought to shed some light on an error that I was seeing a lot back in the day when I was a teenager: after loading some data file e.g. at $C000-$CFFF and then trying to make any change to the BASIC program in memory I would always get the “?OUT OF MEMORY ERROR” message.
Out of memory error message
Why is that? Well, when in direct mode the LOAD command sets the pointer to the start of variables for the BASIC interpreter to the end address+1 of the file that was just loaded, even when the secondary address is odd.
Out of memory error message
Is that correct or not? Well, that depends on whether the LOAD command is understood to only load BASIC programs or also data files without a BASIC program to execute and use such data. From the “Programmer’s reference guide”:
The LOAD statement reads the contents of a program file from tape or disk into memory. […] If LOAD is executed from within a program, the program is RUN. This means that you can use LOAD to “chain” several programs together. None of the variables are cleared during a chain operation.
That should make things clear :)
As I was working at a couple of feature change requests over the weekend, I’ve decided to publish a preview version of TAPClean Front End along with the latest release candidate version of TAPClean itself, 0.32-pre10.
Windows Binaries are available here.
The relevant documentation can be found here.
Posted in Retrocomputing, Technical
Tagged Commodore 64, dumping, games, loaders, preservation, restoration, retrocomputing, software, TAPClean, tapes
I’ve been doing some development on my tool that decodes LN2 sprite-related data and I’ve finally distinguished between frames (how sprites are combined) and animation sequences (how frames are played back):
Animation sequences are scattered in various points in RAM (presumably wherever they could be fit around other data) so I had to come up with something a bit more complicated to support such information. I quite like the result :)
That’s right. I am trying to negotiate on a few things with a local manufacturer in order to get an enclosure for USBhost-64 manufactured. Most of the measurements need to be verified and agreed, but the key thing is that larger volumes mean lower prices, and I’ve got a provisional estimate of about 12 GBP per case for a batch of 100 cases.
In order to cover the costs of PCB manufacturing, connectors, screws, electronic components, and assembly of the lot we would be looking at a final price of 45 GBP plus shipping if I get 100 units produced. The serial version of USBhost-64 would be slightly cheaper at 42 GBP plus shipping.
Now here’s the deal: if there are 100-ish people who commit to buy a serial or parallel version of USBhost-64 before production, I am willing to not only let them have one of these little devices together with the handling driver + software for disk and cartridge, but I’d actually release the software as a group of open-source projects and provide a detailed API documentation for ASM programmers.
If you are interested in a USBhost-64 or you know about somebody who would, feel free to drop me an email. I will try to spread the message around in the next few days when I get a chance. Feel free to do so where appropriate!
Last but not least, if the company providing enclosures can make a good job, I would be looking at mass producing DC2N2, DC2N3 and DC2N4 too :)