Development process

[Eric Christopherson]

Could I get some information on how the firmware is developed? I'm
wondering if it can be compiled with only free tools, what OSs are
supported, what's used for testing, etc. One thing I'm especially
interested in is whether there is an emulator for an actual assembled
uIEC-SD device so it can be tested with OpenCBM or VICE.

Thanks.

--
Eric Christopherson

[Ingo Korb]

Eric Christopherson <echrist...@gmail.com> writes:

> I'm wondering if it can be compiled with only free tools,

Yes, specifically avr-gcc, avr-libc, (GNU) make and Perl

> what OSs are supported,

I know it compiles on Linux, I've heard that it might compile on
FreeBSD, I would guess that it does on OSX and it might even work on
Windows with Cygwin. Assuming that you install an avr-gcc toolchain.

> what's used for testing, etc.

Usually a real C64 and actual hardware.

> One thing I'm especially interested in is whether there is an emulator
> for an actual assembled uIEC-SD device so it can be tested with
> OpenCBM or VICE.

OpenCBM should be able to send commands to a uIEC, but its accelerated
transfer modes are not supported. There is no emulation of any
sd2iec-based device in VICE.

-ik

[Eric Christopherson]

On Tue, Jun 28, 2016 at 1:12 PM, Ingo Korb <m...@akana.de> wrote:

Eric Christopherson <echrist...@gmail.com> writes:

> I'm wondering if it can be compiled with only free tools,

Yes, specifically avr-gcc, avr-libc, (GNU) make and Perl

Great!

 

> what OSs are supported,

I know it compiles on Linux, I've heard that it might compile on
FreeBSD, I would guess that it does on OSX and it might even work on
Windows with Cygwin. Assuming that you install an avr-gcc toolchain.

> what's used for testing, etc.

Usually a real C64 and actual hardware.

> One thing I'm especially interested in is whether there is an emulator
> for an actual assembled uIEC-SD device so it can be tested with
> OpenCBM or VICE.

OpenCBM should be able to send commands to a uIEC, but its accelerated
transfer modes are not supported. There is no emulation of any
sd2iec-based device in VICE.

OK. I've been playing around with the real uIEC in VICE with OpenCBM, just to get a feel for how it works with JiffyDOS (which I never had back in the day), how navigating directories and images works, etc. I'm unsure what you mean by "accelerated transfer modes" -- my hypotheses are that you mean either fast serial/burst mode a la the 1571 and 1581, or speed loaders like were available for the 1541; or (on the other hand) specific modes of using the X*1541 and OpenCBM. I have noticed that OpenCBM's cbmcopy command allows you to upload a turbo program to the C= device (the specific code depends on the model cbmcopy thinks it is) and also allows you to specify the X*1541 communication mode; for me only the "original" (=slowest) mode works with the uIEC. So when you say "accelerated transfer modes" do you mean one of the things I just described?

And why are accelerated transfer modes not supported in OpenCBM?

(When I mentioned OpenCBM on VICE on IRC, groepaz said he thinks the OpenCBM support in VICE is crap and useless and should be removed, which horrified me!)

 

-ik

--
You received this message because you are subscribed to the Google Groups "µIEC Users Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uIEC-users+...@googlegroups.com.
To post to this group, send email to uIEC-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/uIEC-users/uk2h9npx5.fsf%40dragon.akana.de.
For more options, visit https://groups.google.com/d/optout.

--

        Eric Christopherson

[silv...@wfmh.org.pl]

> On 2016-06-28, at 20:32, Eric Christopherson <echrist...@gmail.com> wrote:
>
>
> And why are accelerated transfer modes not supported in OpenCBM?

AFAIU OpenCBM accelerated modes are not supported in uIEC. Some others are.

--
SD!

[Ingo Korb]

Eric Christopherson <echrist...@gmail.com> writes:

> I have noticed that OpenCBM's cbmcopy command allows you to upload a
> turbo program to the C= device (the specific code depends on the model
> cbmcopy thinks it is) and also allows you to specify the X*1541
> communication mode; for me only the "original" (=slowest) mode works
> with the uIEC. So when you say "accelerated transfer modes" do you
> mean one of the things I just described?
>
> And why are accelerated transfer modes not supported in OpenCBM?

Fastloaders of any kind are generally unsupported by sd2iec because they
upload binary code to the drive's memory and execute it on the drive's
processor. But because sd2iec is not a 1541/71/... emulator, but instead
an SD card drive for the Commodore serial bus, it has no 6502 or
6502-emulation to run this code and a program that tries to do this
fails.

There are a few, very specific exceptions where sd2iec recognizes
the uploaded code and runs a manually-reimplemented version of it to
provide compatibility with some popular fastloaders, for example the one
used in the Final Cartridge III or the Epyx Fastload cartridge. The code
used by OpenCBM is not on that list though and I don't see any reason to
change this - if you have a PC, you can just use an USB SD card reader
instead, which provides much faster and more convenient access.

> (When I mentioned OpenCBM on VICE on IRC, groepaz said he thinks the
> OpenCBM support in VICE is crap and useless and should be removed, which
> horrified me!)

I fully agree with groepaz on that point. The OpenCBM support in VICE is
basically a high-level drive emulation that forwards the commands and
file accesses to an external drive, resulting in poor compatibility even
if you try to access a 1541 through it. This makes the feature rather
useless in practice, it would be much better if people would just use
d64copy to create an image file and load that into VICE than trying to
access a real 1541 from VICE with OpenCBM.

-ik

[Pete Rittwage]

Agree, this should never have been implemented. Every question I've ever
seen about it dealt with the limitations. Has anyone ever used it and it
worked for what they wanted it to? :)

-Pete Rittwage

[silv...@wfmh.org.pl]

> On 2016-06-28, at 22:09, Pete Rittwage <pe...@rittwage.com> wrote:
>
> Has anyone ever used it and it
> worked for what they wanted it to? :)

I /think/ I managed to read the directory once (or maybe twice)…

--
SD!

[Greg King]

On Tuesday, June 28, 2016 at 4:09:39 PM UTC-4, Pete Rittwage wrote:

> Eric Christopherson <echrist...@gmail.com> writes:
>>
>> (When I mentioned OpenCBM on VICE on IRC, groepaz said he thinks the

>> OpenCBM support in VICE is crap and useless; and, should be removed, which

>> horrified me!)
>
> I fully agree with groepaz on that point. The OpenCBM support in VICE is
> basically a high-level drive emulation that forwards the commands and
> file accesses to an external drive, resulting in poor compatibility even

> if you try to access a 1541 through it. That makes the feature rather
> useless in practice; it would be much better if people would just use
> d64copy to create an image file; and, load that into VICE than trying to

> access a real 1541 from VICE with OpenCBM.

Agree, this should never have been implemented. Every question I've ever

seen about it dealt with the limitations. Has anyone ever used it; and, it

worked for what they wanted it to? :)

Absolutely yes!  I often used my real CMD FD2000 drive through OpenCBM and ZoomFloppy, rather than used the FD2000 emulation in VICE (I started doing it back when there was no FD2000 emulation).

And, there is the whole point of this thread.  A PC USB SD card reader has nothing to do with sd2iec!  If one wants to use VICE to help debug a program that uses sd2iec DOS commands, then there is no alternative to OpenCBM!  The same is true of other adapters, such as XD2031 and PetSD.

[Eric Christopherson]

On Tue, Jun 28, 2016, Ingo Korb wrote:
> Eric Christopherson <echrist...@gmail.com> writes:
>
> > I have noticed that OpenCBM's cbmcopy command allows you to upload a
> > turbo program to the C= device (the specific code depends on the model
> > cbmcopy thinks it is) and also allows you to specify the X*1541
> > communication mode; for me only the "original" (=slowest) mode works
> > with the uIEC. So when you say "accelerated transfer modes" do you
> > mean one of the things I just described?
> >
> > And why are accelerated transfer modes not supported in OpenCBM?
>
> Fastloaders of any kind are generally unsupported by sd2iec because they
> upload binary code to the drive's memory and execute it on the drive's
> processor. But because sd2iec is not a 1541/71/... emulator, but instead
> an SD card drive for the Commodore serial bus, it has no 6502 or
> 6502-emulation to run this code and a program that tries to do this
> fails.
>
> There are a few, very specific exceptions where sd2iec recognizes
> the uploaded code and runs a manually-reimplemented version of it to
> provide compatibility with some popular fastloaders, for example the one
> used in the Final Cartridge III or the Epyx Fastload cartridge. The code
> used by OpenCBM is not on that list though and I don't see any reason to
> change this - if you have a PC, you can just use an USB SD card reader
> instead, which provides much faster and more convenient access.

OK. I'm still not sure though what specific "accelerated transfer modes"
you were referring to in the email further upthread (i.e. when you said

"OpenCBM should be able to send commands to a uIEC, but its accelerated

transfer modes are not supported."). Would you care to clarify?

--
Eric Christopherson

[Greg King]

On Tuesday, June 28, 2016 at 6:42:21 PM UTC-4, Eric Christopherson wrote:

On Tue, Jun 28, 2016, Ingo Korb wrote:
> Eric Christopherson <echrist...@gmail.com> writes:
>
> > I have noticed that OpenCBM's cbmcopy command allows you to upload a
> > turbo program to the C= device (the specific code depends on the model
> > cbmcopy thinks it is) and also allows you to specify the X*1541
> > communication mode; for me only the "original" (=slowest) mode works
> > with the uIEC. So when you say "accelerated transfer modes" do you
> > mean one of the things I just described?

OK. I'm still not sure, though, what specific "accelerated transfer modes"
you were referring to in the email further upthread (i.e., when you said
"OpenCBM should be able to send commands to a uIEC; but, its accelerated

transfer modes are not supported."). Would you care to clarify?

It seems obvious to me.  Ingo quoted you, to show that you answered your own question -- yes, it is that "turbo" code, that cbmcopy wants to upload to a drive.  It works on a CBM drive; it works on a CMD drive; it can't work on a uIEC (as you said, "only the slowest mode works").

[RETRO Innovations]

On 6/28/2016 1:12 PM, Ingo Korb wrote:
> Eric Christopherson <echrist...@gmail.com> writes:
>
>> I'm wondering if it can be compiled with only free tools,
> Yes, specifically avr-gcc, avr-libc, (GNU) make and Perl
>
>> what OSs are supported,
> I know it compiles on Linux, I've heard that it might compile on
> FreeBSD, I would guess that it does on OSX and it might even work on
> Windows with Cygwin. Assuming that you install an avr-gcc toolchain.

I can confirm it works on Windows (7 and 10). Install Atmel Studio 7
for the avr-gcc toolchain, and cygwin for the rest.


--
RETRO Innovations, Contemporary Gear for Classic Systems
www.go4retro.com
store.go4retro.com

[Eric Christopherson]

OK. I sometimes have trouble feeling confident that my initial
interpretation of an answer is the correct one. It didn't help matters
any that I had mentioned two avenues of potential speed boosting built
into OpenCBM (so I wasn't sure which one); and also I interpreted Ingo's
words to mean that there was some sort of high-speed support when using
an actual C= computer. (True, there definitely is JiffyDOS support in
there; I'm not sure if that does anything in VICE when you have the ROMs
installed in the virtual machine. I'm guessing not, now.)

--
Eric Christopherson

[Eric Christopherson]

On Tue, Jun 28, 2016 at 1:12 PM, Ingo Korb <m...@akana.de> wrote:

Eric Christopherson <echrist...@gmail.com> writes:

> I'm wondering if it can be compiled with only free tools,

Yes, specifically avr-gcc, avr-libc, (GNU) make and Perl

> what OSs are supported,

I know it compiles on Linux, I've heard that it might compile on
FreeBSD, I would guess that it does on OSX and it might even work on
Windows with Cygwin. Assuming that you install an avr-gcc toolchain.

OK, thanks. I was able to get it built under Linux. But when I put the .bin on the card (in the root of partition 1), it didn't seem to read it in; the version string is the same as before (something including g73a4dfc). I seem to recall the bootloader checks to see if it's a valid firmware, and not the one currently installed. How does it do that?

(I'm thinking it was via CRC. I see that a CRC is generated in the build process.)

[RETRO Innovations]

On 6/29/2016 2:15 PM, Eric Christopherson wrote:

On Tue, Jun 28, 2016 at 1:12 PM, Ingo Korb <m...@akana.de> wrote:

Eric Christopherson <echrist...@gmail.com> writes:

> I'm wondering if it can be compiled with only free tools,

Yes, specifically avr-gcc, avr-libc, (GNU) make and Perl

> what OSs are supported,

I know it compiles on Linux, I've heard that it might compile on
FreeBSD, I would guess that it does on OSX and it might even work on
Windows with Cygwin. Assuming that you install an avr-gcc toolchain.

OK, thanks. I was able to get it built under Linux. But when I put the .bin on the card (in the root of partition 1), it didn't seem to read it in; the version string is the same as before (something including g73a4dfc). I seem to recall the bootloader checks to see if it's a valid firmware, and not the one currently installed. How does it do that?

(I'm thinking it was via CRC. I see that a CRC is generated in the build process.)

Look at the Makefile.  You need to edit to to create a DEV firmware.

Jim

[Eric Christopherson]

On Wed, Jun 29, 2016, RETRO Innovations wrote:
> On 6/29/2016 2:15 PM, Eric Christopherson wrote:
> >On Tue, Jun 28, 2016 at 1:12 PM, Ingo Korb <m...@akana.de
> ><mailto:m...@akana.de>> wrote:
> >
> > Eric Christopherson <echrist...@gmail.com

> > <mailto:echrist...@gmail.com>> writes:
> >
> > > I'm wondering if it can be compiled with only free tools,
> >
> > Yes, specifically avr-gcc, avr-libc, (GNU) make and Perl
> >
> > > what OSs are supported,
> >
> > I know it compiles on Linux, I've heard that it might compile on
> > FreeBSD, I would guess that it does on OSX and it might even work on
> > Windows with Cygwin. Assuming that you install an avr-gcc toolchain.
> >
> >
> >OK, thanks. I was able to get it built under Linux. But when I put the
> >.bin on the card (in the root of partition 1), it didn't seem to read it
> >in; the version string is the same as before (something including
> >g73a4dfc). I seem to recall the bootloader checks to see if it's a valid
> >firmware, and not the one currently installed. How does it do that?
> >
> >(I'm thinking it was via CRC. I see that a CRC is generated in the build
> >process.)
> Look at the Makefile. You need to edit to to create a DEV firmware.

Hmm, I've done some looking in there and the .mk files and config files;
but I'm still not sure what I'm looking for.

--
Eric Christopherson

[Eric Christopherson]

I found this in Makefile.main:

    # Forces bootloader version to 0, comment out or leave empty for release

    PRERELEASE = alpha0 

I commented it out, but still didn't see any change in the version string on the device. I seem to remember reading that a prerelease version/version 0 will make the bootloader always load it, but I'm not sure where I got that idea from; in any event, it either isn't taking effect or the error 73 version string isn't changing for whatever reason.

I'm also curious as to how the strings 84 and g73a4dfc (in 73,sd2iec v1.0.0alpha0-84-g73a4dfc,00,) are generated. At first I was thinking 84 was for 1284, but now that I think about it I think the uIEC uses a 1281.

--

        Eric Christopherson

[Eric Christopherson]

Well, judging by the other release filenames, I guess 84 is just a sequential release number. I've been scouring my search history to figure out why I even put g73a4dfc (from 2014; apparently same as release 0.10.3?) on it in the first place. But no matter; I've just discovered that I get wildly different results every time I try to push these large files from my PC over OpenCBM. OpenCBM's cbmcopy shows 00, ok,00,00 at the end of the transfer, but quite often the resulting file is much too small to be complete (even as small as 20 blocks).

I guess I'll have to either figure out why OpenCBM and my cable aren't working right, or just go back to moving the SD card from one reader/writer to another.

--

        Eric Christopherson

[Eric Christopherson]

I have been able to verify that a slight change to the firmware, followed copying the .bin onto the SD, plugging the SD into the uIEC, and resetting the uIEC does cause the bootloader to load the new firmware.

Now if I could only get OpenCBM to transfer the file over IEC so I don't have to constantly take the card out of one reader/writer and put it in a different one. I think I'm going to break out my 1581 and see if OpenCBM can at least transfer the .bin to a floppy reliably (so I can rule out OpenCBM and the cable as culprits).

--

        Eric Christopherson

[Eric Christopherson]

On Fri, Jul 01, 2016, Eric Christopherson wrote:
> >> I'm also curious as to how the strings 84 and g73a4dfc (in 73,sd2iec
> >> v1.0.0alpha0-84-g73a4dfc,00,) are generated. At first I was thinking 84 was
> >> for 1284, but now that I think about it I think the uIEC uses a 1281.
> >>
> >
> > Well, judging by the other release filenames, I guess 84 is just a
> > sequential release number. I've been scouring my search history to figure
> > out why I even put g73a4dfc (from 2014; apparently same as release
> > 0.10.3?) on it in the first place. But no matter; I've just discovered that
> > I get wildly different results every time I try to push these large files
> > from my PC over OpenCBM. OpenCBM's cbmcopy shows 00, ok,00,00 at the end of
> > the transfer, but quite often the resulting file is much too small to be
> > complete (even as small as 20 blocks).
> >
> > I guess I'll have to either figure out why OpenCBM and my cable aren't
> > working right, or just go back to moving the SD card from one reader/writer
> > to another.
> >
>
> I have been able to verify that a slight change to the firmware, followed
> copying the .bin onto the SD, plugging the SD into the uIEC, and resetting
> the uIEC does cause the bootloader to load the new firmware.
>
> Now if I could only get OpenCBM to transfer the file over IEC so I don't
> have to constantly take the card out of one reader/writer and put it in a
> different one. I think I'm going to break out my 1581 and see if OpenCBM
> can at least transfer the .bin to a floppy reliably (so I can rule out
> OpenCBM and the cable as culprits).

Just FYI: I just tried cbmcopy's "original" transfer mode to write to my
real 1581, and it also acted like it completed a large file (a .d71
image), but the resulting file was much smaller. So there must be
something wrong with the original transfer mode in OpenCBM. I was able
to correctly write and read the image to the 1581 using the serial2
mode, but that mode doesn't work with the uIEC.

--
Eric Christopherson