Page 3 of 3
Posted: Sat Apr 27, 2013 4:55 pm
by Mike
pallas wrote:On a side note, do you think the "unit" command should be renamed to "dev"? I used the "unit" term because it's used by cc65, which covers many non-cbm systems as well so it must be generic, but I understand the most used cbm term for it is "device", shortcut to "dev".
Would make sense, at least in principle. In CBM DOS, 'unit' actually refers to the
drive number, which is normally fixed to 0 on a single-disk drive, but can be 0 or 1 on a dual-disk drive (like the 8250LP). In BASIC V4, you can tell the drive to show the directory of the disk in unit 1 on device #8 like thus:
CATALOG D8 ON U1, or even copy the contents of a disk in unit 0 to another disk in unit 1 (on the same drive!) with
BACKUP U0 TO U1.
However, as the number of dual-disk drives is supposedly rather small, it's more an academic problem. They'd all have to be connected to the VIC-20 over IEEE anyway, and then there would be yet another KERNAL expansion on a cartridge in play - where cc65 again would be required to play nice with.
Nethertheless, programs might use the drive number/unit explicitly in the command channel, for example in
OPEN 15,8,15, "S0:EXAMPLE.PRG" : CLOSE15, where the drive number is optional between the command (here,
Scratch) and the colon. That had been another thing that cropped up during the beta-test phase of the FE3 RAM Disk.
Posted: Sun Apr 28, 2013 10:04 am
by freshlamb
Just a note. The MSD SD-1 is a dual disk drive that uses the serial line. I only mention this because I own one.
Posted: Sun Apr 28, 2013 10:14 am
by pallas
I'll have a look at dual drives by vice emulation as soon as I'm done with the priority things like loading multi bank carts and finish testing and fixing all the commands.
Currently I'm working on copy and move between devices, it's already working fine!
Posted: Sun Apr 28, 2013 2:21 pm
by RobertBe
freshlamb wrote:The MSD SD-1 is a dual disk drive...
The MSD SD-1 has a single 5 1/4" TEC floppy disk mechanism. The MSD SD-2 has two floppy disk mechanisms.
Writing from Los Angeles,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
July 27-28 Commodore Vegas Expo v9 -
http://www.portcommodore.com/commvex
Posted: Tue Apr 30, 2013 5:40 am
by pallas
In order to read from one device and write to another, I switched from using open/read to cbm_open/cbm_read.
But, if I try to cbm_open a non-existing file, it doesn't return any error, nor does cbm_read, so I end up without any error message to the user and an empty target file
Any clues?
Here is the code:
Code: Select all
if (cbm_open(14, <<dev>>, CBM_READ, src)) {
perror(srcName);
return FALSE;
}
if (cbm_open(15, <<dev>>, CBM_WRITE, tmpdest)) {
perror(destName);
cbm_close(14);
return FALSE;
}
do {
rcc = cbm_read(14, buf, BUF_SIZE);
if (rcc < 0 || cbm_write(15, buf, rcc) < 0) goto error_exit;
} while (rcc == BUF_SIZE);
if (rcc < 0) {
perror(srcName);
goto error_exit;
}
cbm_close(14);
cbm_close(15);
return TRUE;
error_exit:
cbm_close(14);
cbm_close(15);
return FALSE;
cbm_open() always returns 0 and rcc is 0 even if the file doesn't exists.
Posted: Mon May 06, 2013 3:12 am
by pallas
I still haven't found a solution to the problem, this is getting frustrating.
Maybe I should really go back to the latest stable release of cc65 and make cbmsh compatible with it...
Posted: Mon May 06, 2013 5:00 am
by FD22
What was the reason for not using the latest stable release anyway?
If it was something quite fundamental to the way the project works, it's a decision between switching and reworking to overcome that defecit, or sticking with the release you're on and writing this subroutine in assembly. Which would be the least work?
Posted: Mon May 06, 2013 8:59 am
by pallas
yes, exactly.
the stable version has, among other things, a different way of dealing with the "current unit" (device), so if I was to make it compatible with the stable version, I would then need to undo the changes once there is a new stable release (assuming there will ever be one...).
Or, as you said, I could write my own routines, based on the asm or C versions of the cc65 sources.
I think the first solution is better, because there are other known issues which are probably due to some of the changes introduced recently in the cc65 sources. It just looked lame, and not fun at all, to got backwards
and, you know, when you do a program for fun, and you run into weird bugs and get frustrated, you start thinking "is it really worth? better save my sleep".
Posted: Mon Jul 08, 2013 5:06 am
by pallas
Great cc65 news! They started posting updates on svn again!
I've tried compiling cbmsh with the latest svn commit and... it freezes just after running it
I guess I will have to wait a little bit more
Or, start bebugging but I really do not have the time.
Posted: Mon Jul 15, 2013 5:25 pm
by groepaz
actually the repository moved to github:
https://github.com/oliverschmidt/cc65 ... the old svn is abbandoned
Posted: Tue Jul 16, 2013 2:22 am
by pallas
thanks, I didn't notice.
I had a look at the git repository and it looks like the svn is fresher (it's updated more than once daily, while the git last commit is jul 10).
Posted: Tue Jul 16, 2013 8:47 pm
by groepaz
which svn are you talking about? the one run by UZ (ie the old one) hasnt been updated at all for a while.
Posted: Wed Jul 17, 2013 2:08 am
by pallas
the url is:
svn://svn.cc65.org/cc65/trunk
#svn log -r HEAD
------------------------------------------------------------------------
r6014 | uz | 2013-07-16 12:22:11 +0200 (Tue, 16 Jul 2013) | 2 lines
Added functions to copy and move typed values.
Posted: Wed Jul 17, 2013 3:04 am
by pallas
well I don't know what they are doing with the svn, but it doesn't even compile the compiler.
the git works much better, it can compile and the resulting cbmsh runs, even though the problems I had with some cbm_() calls are still there.