Ciderpress for OS/X?
datajerk
as Ciderpress for Windows? Thanks.
Toinet
> Is there an equivalent for OS/X that provides the same functionality
> as Ciderpress for Windows? Thanks.
I don't know if there is an equivalent but I will tell you how I do: I
have Parallels and XP on a disk image and whenever I double-click an
Apple II disk image, Ciderpress is launched and thanks to Parallel
shared folders I can add files.
The drawback is that I cannot copy from/to volumes from my Compact
Flash card with Parallels/Ciderpress because OS/X does not mount it as
it is unable to recognize it.
antoine
magnusfalkirk
> Is there an equivalent for OS/X that provides the same functionality
> as Ciderpress for Windows? Thanks.
The closest thing I found to Ciderpress for OS X is ADFS (Apple DOS
File System). It won't open up SHK files for for any normal Apple II
disk image it will open it and you can transfer files to and from the
disk image. You can find it here: http://www.lazilong.com/apple_II/adfs/downloads/
Dean
Ivan Drucker
> Flash card with Parallels/Ciderpress because OS/X does not mount it as
> it is unable to recognize it.
If you instruct Parallels to use your USB card reader, that should allow
Windows (and hence CiderPress) to directly interact with your card -- so you
could move your images in OS X through your shared folder to the card
mounted in CiderPress. I've never tried. Does that happen?
John B. Matthews
<04dba0e7-333c-44b1...@p23g2000vbl.googlegroups.com>,
datajerk <data...@gmail.com> wrote:
> Is there an equivalent for OS/X that provides the same functionality
> as Ciderpress for Windows? Thanks.
It's not quite as full featured as CiderPress, but I like AppleCommander:
<http://applecommander.sourceforge.net/>
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
PZ
> In article
> <04dba0e7-333c-44b1-aadc-7282c2653...@p23g2000vbl.googlegroups.com>,
>
> datajerk <dataj...@gmail.com> wrote:
> > Is there an equivalent for OS/X that provides the same functionality
> > as Ciderpress for Windows? Thanks.
>
> It's not quite as full featured as CiderPress, but I like AppleCommander:
>
> <http://applecommander.sourceforge.net/>
>
> --
> John B. Matthews
> trashgod at gmail dot com
> <http://sites.google.com/site/drjohnbmatthews>
There's also something in the works for OSX.
- Paul
kgagne
used to find Shrink II invaluable:
http://www.syndicomm.com/mac/index.html
Unfortunately, it's not yet been updated for OS X, meaning it won't
run on my Intel Mac. :-(
-Ken
ict@ccess
pretty much the only computer you need that can access all the old
drives. Not only can you run OSX 10.3.9 on them to access the
journalled drives under OSX but you can also boot into OS9 which
allows you to read Prodos, HFS, HFS extended, FAT, and FAT16 from both
the floppy and the zip drive. And then if you want to transfer files
to a computer with NTFS, there is file sharing. My G3 stays plugged
into a router and nothing is easier to transfer all my Apple II files
to the G3 with the floppy drive, then on to either my G5 with OSX or
PC with Windows XP.
I said it once before, and I will say it again. You can't beat an old
Power Mac for emulation programs. Also there is quite a selection for
emulation software as well for Macintosh. From Nintendo's game boy to
the Genesis to Colecovision to the Commodore 64. What a great hobby
this is!
Rob
Drew
I have a number of powermacs and OS 9 never seems reliable at reading/
writing prodos disks (well 9.2.2). I find 8.6 on my Wallstreet works
perfectly for reading and writing Prodos disks and when i had a
powermac 7300 with 8.6 (gone now due to lack of space) that also
worked well. Did 9 have issues or is there a why to make that work
properly with Prodos? I tried formatting a 1.4mb floppy on my ibook g3
with a USB floppy and it started to format then just hang :(
Drew
Ivan X
extension, which works just great, at least under 7.5.5 where I use it. The
latest version, 1.2.1, is found on the disk for the Apple IIe Card (for Mac
LC) 2.2.1 software.
ProDOS File System was then merged into PC Exchange 2.0 in 7.5. (Version 2.2
was in Mac OS 8.1.)
Finally, that was merged into File Exchange 3.0, in 8.5.
I'm guessing ProDOS volume support was less of a priority over time, so
perhaps the older extensions work better. If you don't need PC disk support,
try disabling File Exchange and using one of the older extensions in its
place, and see if things are any better. (You can use TomeViewer to extract
PC Exchange from the 7.5.3 or 8.1 update installers; ProDOS File System on
the IIe Card disk isn't in a tome and is readly copyable.)
Alternatively, disable File Exchange and/or the older extensions if present,
and use the similarly named but entirely different Apple File Exchange 7.0
application which is on the System 7.0.1 and 7.1 Tidbits disk. It will only
let you copy files to and from your ProDOS volume, but otherwise will not
integrate it into Mac OS. It does have a few benefits, such as not creating
Mac-specific files like DESKTOP or forked files which can't be read in
ProDOS 8.
The IIe Card software (for ProDOS File System) and System 7.0.1 (for Apple
File Exchange) and System 7.5.3 or 8.1 update (for PC Exchange) are
downloadable from
http://www.info.apple.com/support/oldersoftwarelist.html
datajerk
> Is there an equivalent for OS/X that provides the same functionality
> as Ciderpress for Windows? Thanks.
Thanks for all of your input. I have been using CiderPress with
Windows XP/VMware on my MacBook Pro without issue except the overhead
of running two operating systems. I did give Wine a try. I think I
can make it work, but am more interested in a native solution. Of the
recommendations posted I found AppleCommander (Thanks John) to be
exactly what I was looking for. It is missing a few features that I
use (e.g. renaming files), but that can be easily worked around.
"What a great hobby this is!" -- Rob
Yes it is! I have not used an Apple II+ or //e in over 20 years.
Great fun. I remember learning C in the 80s and wished I could write
programs for my II+ at home. But I never could get the compilers.
Now, 20+ years later, I am using Aztec C (surprisingly complete!) for
DOS in DOSBox on my MacBook Pro to cross compile for an Apple //e
target. Then I use AppleCommander to drop the SYS file onto a PRODOS8
diskette image, boot up in Virtual ][ (just too awesome for words),
and voila, I am up and running. Great stuff. Thanks for all your
help.
Sheppy
The problem with ProDOS disks on Macs is usually oriented about the
type of drive. 3.5" disks written in the newer, manual-inject 3.5"
drives used in later Macs (as opposed to the auto-inject drives that
grab the disk from you and pull it in) tend to write disks that don't
work reliably in Apple II drives.
Sheppy
John B. Matthews
<209ebd20-7710-4e9d...@r34g2000vba.googlegroups.com>,
datajerk <data...@gmail.com> wrote:
Excellent. I'm running <http://www.ubuntu.com/> in
<http://www.virtualbox.org/>; I'll have to look into
<http://www.dosbox.com/>.
To save typing in cross-development, I often use a Makefile to pull
strings: <http://home.roadrunner.com/~jbmatthews/a2/cross.html>.
ict@ccess
> > writing prodos disks (well 9.2.2). I find 8.6 on my Wallstreet works
> > perfectly for reading and writing Prodos disks and when i had a
> > powermac 7300 with 8.6 (gone now due to lack of space) that also
> > worked well. Did 9 have issues or is there a why to make that work
> > properly with Prodos? I tried formatting a 1.4mb floppy on my ibook g3
> > with a USB floppy and it started to format then just hang :(
>
> The problem with ProDOS disks on Macs is usually oriented about the
> type of drive. 3.5" disks written in the newer, manual-inject 3.5"
> drives used in later Macs (as opposed to the auto-inject drives that
> grab the disk from you and pull it in) tend to write disks that don't
> work reliably in Apple II drives.
>
> Sheppy
I'll admit I also have trouble copying Prodos disks with the Mac
Finder, but me thinks that has to do with the driver in file
exchange. I find that the "Bernie 2 the Rescue" emulator has way
more success in copying files within the emulator than from the Mac
Finder desktop.
Rob
Bill Buckels
"John B. Matthews" <nos...@nospam.invalid> wrote:
>Excellent. I'm running <http://www.ubuntu.com/>
Excellent. Then follow the links below and install Aztec C per my
instructions then compile the code to set the Apple //e into 80 column mode
(recently posted in the "80-column mode with Aztec C SYS files?" thread).
http://www.aztecmuseum.ca/compilers.htm#applecross
Bill Buckels
"Bill Buckels" <bbuc...@mts.net> wrote:
>install Aztec C per my instructions
Here's some better instructions for ubuntu:
http://www.aztecmuseum.ca/docs/linux.txt
The link that I posted previously was too generic.
John B. Matthews
"Bill Buckels" <bbuc...@mts.net> wrote:
> "John B. Matthews" <nos...@nospam.invalid> wrote:
>
> > Excellent. I'm running <http://www.ubuntu.com/> in
> > <http://www.virtualbox.org/>; I'll have to look into
> > <http://www.dosbox.com/>.
> Excellent. Then follow the links below and install Aztec C per my
> instructions then compile the code to set the Apple //e into 80
> column mode (recently posted in the "80-column mode with Aztec C SYS
> files?" thread).
>
> http://www.aztecmuseum.ca/compilers.htm#applecross
> http://www.aztecmuseum.ca/docs/linux.txt
I'm not sure why I'd run Aztec in dosemu on Ubuntu in VirtualBox on Mac
OS, when Aztec runs fine in DOSBox on Mac OS. Well, except for the
additional security. :-)
I'm a Kyan kinda guy anyway. Hey, I can see my home page from here!
<http://www.appleoldies.ca/kix/index.htm>
Bill Buckels
"John B. Matthews" <nos...@nospam.invalid> wrote:
>I'm not sure why I'd run Aztec in dosemu on Ubuntu in VirtualBox on Mac OS,
>when Aztec runs fine in DOSBox on Mac OS. Well, except for the additional
>security. :-)
Just pulling your leg of course:)
>I'm a Kyan kinda guy anyway. Hey, I can see my home page from here!
<http://www.appleoldies.ca/kix/index.htm>
But of course. Good to see that it's still there:)
Over and Under,
Bill
datajerk
> In article
> <209ebd20-7710-4e9d-b112-2a363bd32...@r34g2000vba.googlegroups.com>,
>
>
>
> datajerk <dataj...@gmail.com> wrote:
> > On Aug 9, 10:14 am, datajerk <dataj...@gmail.com> wrote:
> > > Is there an equivalent for OS/X that provides the same functionality
> > > as Ciderpress for Windows? Thanks.
>
> > Thanks for all of your input. I have been using CiderPress with
> > Windows XP/VMware on my MacBook Pro without issue except the overhead
> > of running two operating systems. I did give Wine a try. I think I
> > can make it work, but am more interested in a native solution. Of the
> > recommendations posted I found AppleCommander (Thanks John) to be
> > exactly what I was looking for. It is missing a few features that I
> > use (e.g. renaming files), but that can be easily worked around.
>
> > "What a great hobby this is!" -- Rob
>
> > Yes it is! I have not used an Apple II+ or //e in over 20 years.
> > Great fun. I remember learning C in the 80s and wished I could write
> > programs for my II+ at home. But I never could get the compilers.
> > Now, 20+ years later, I am using Aztec C (surprisingly complete!) for
> > DOS in DOSBox on my MacBook Pro to cross compile for an Apple //e
> > target. Then I use AppleCommander to drop the SYS file onto a PRODOS8
> > diskette image, boot up in Virtual ][ (just too awesome for words),
> > and voila, I am up and running. Great stuff. Thanks for all your
> > help.
>
> Excellent. I'm running <http://www.ubuntu.com/> in
> <http://www.virtualbox.org/>; I'll have to look into
> <http://www.dosbox.com/>.
I like DOSBox because it emulates DOS and x86 without any fuss and
runs on just about anything (e.g. Power Macs). And unlike bochs and
other some other virtual environments my DOSBox runs on top of an
existing OS/X, Linux, etc... directory allowing me to code using vi in
an xterm.
> To save typing in cross-development, I often use a Makefile to pull
> strings: <http://home.roadrunner.com/~jbmatthews/a2/cross.html>.
I am using the AppleX mentioned below. It includes make thus making C
programming easy.
Bill Buckels
"datajerk" <data...@gmail.com> wrote:
>I am using the AppleX mentioned below. It includes make thus making C
>programming easy.
I actually bundled this with the make utility from olde Turbo C version
2.01... I liked it better once upon a tyme. The point in providing AppleX
was of course a no-fuss installation. Nothing is dumb simpler than MS-DOS.
Another nice thing about Aztec C is the shear number of library routines
that are kicking-around for the Apple II. Bite me, but this really is easy
isn't it?
Bill
Alex Freed
>
> Another nice thing about Aztec C is the shear number of library routines
> that are kicking-around for the Apple II. Bite me, but this really is easy
> isn't it?
>
Did anyone compare the code generated by Aztec with that from cc65? I'm
more concerned about the size than the speed.
-Alex.
datajerk
I tried, but I could not get cc65 to compile my code. It errors with
too many local variables. So I gave up. But I would like to compare
the speed of my pi.c program. cc65 vs Aztec. mano-a-mano.
datajerk
Bill, it is too easy thanks to you:
1. Unzip.
2. Type 'aztec.bat'
3. Copy one of Bill's makefiles. Mod to taste.
4. Write your C program.
5. Type 'make'
Thanks again!
John B. Matthews
<1f0f92e3-f832-4b32...@q40g2000prh.googlegroups.com>,
datajerk <data...@gmail.com> wrote:
[...]
> > Did anyone compare the code generated by Aztec with that from cc65?
> > I'm more concerned about the size than the speed.
>
> I tried, but I could not get cc65 to compile my code. It errors with
> too many local variables. So I gave up. But I would like to compare
> the speed of my pi.c program. cc65 vs Aztec. mano-a-mano.
<http://sense.net/~egan/apple2e_aztec_c/pi.c>
$ cl65 -O2 --static-locals -t apple2enh pi.c
I get an executable of 12377 bytes.
<code>
$ diff pi.c aztexpi.c
18d17
< #include <stdlib.h>
21d19
< #include <conio.h>
271,272c269,270
< clrscr();
< __asm__ ("jsr %w", 0xc300);
---
> scr_clear();
> crt80();
276c274
< c = cgetc();
---
> c = getch();
288c286
< clrscr();
---
> scr_clear();
295,296c293,294
< cgetc();
< exit(1);
---
> getch();
> _exit(1);
315,316c313,314
< cgetc();
< exit(0);
---
> getch();
> _exit(0);
</code>
Zaleski
Let us know of your benchmarks, this would be a good one. It'd be
nice to get a Kyan benchmark vs. these two as well. I'd think C would
get the edge, but a cool test nevertheless.
- Paul
datajerk
> In article
>
> datajerk <dataj...@gmail.com> wrote:
>
> [...]
>
> > > Did anyone compare the code generated by Aztec with that from cc65?
> > > I'm more concerned about the size than the speed.
>
> > I tried, but I could not get cc65 to compile my code. It errors with
> > too many local variables. So I gave up. But I would like to compare
> > the speed of my pi.c program. cc65 vs Aztec. mano-a-mano.
>
> <http://sense.net/~egan/apple2e_aztec_c/pi.c>
>
> $ cl65 -O2 --static-locals -t apple2enh pi.c
Apparently I didn't try hard enough. Thanks for the tip. I too get a
12377 byte pi.
I am having a few challenges running it however. I have been unable
to use Ciderpress or AppleCommander to put this on a disk image and
run it. However a2tools does work--DOS3.3 images only.
So now I have a DOS3.3 image with pi, when I BRUN PI I get screen
garbage when the following code is run:
printf("Start time: %s\n",asctime(localtime(&starttime)));
This code works with any *NIX and Aztec C. My emulator has the
Thunderclock card in slot 7. If I use the no-slot clock it also gets
garbage. So I am unable to time this without using a wall-clock. Any
ideas?
Thanks.
Bill Buckels
"datajerk" <data...@gmail.com> wrote:
>Apparently I didn't try hard enough.
I never did get cc65 running. I got a broken snapshot and some attitude
about foodchains and toolchains and just got turned-off so I guess I never
tried hard enough either. No great loss from what I see. Aztec C is well
documented and works well on the Apple II in the following areas:
1. ProDOS SYS programs
2. DOS 3.3 BIN programs
3. Overlay Linker Support
4. CP/M 80 Programs
And
5. ProDOS Unix Like Shell Programs
6. Floating Point Support
Aztec C Rocks!
Bill Buckels
"datajerk" <data...@gmail.com> wrote:
>Bill, it is too easy thanks to you:
I couldn't agree more heartily:)
>1. Unzip.
>2. Type 'aztec.bat'
>3. Copy one of Bill's makefiles. Mod to taste.
>4. Write your C program.
>5. Type 'make'
>Thanks again!
You're welcome. So is everyone else. On the topic of point 4 above (4.
Write your C program.)
A large body of sample source and library routines is on the Aztec C Website
from a number of contributors and I continue to receive more.
Here's some acknowledgements (there are others)
http://www.aztecmuseum.ca/intro.htm#acknowledgements
http://www.aztecmuseum.ca/docs/index.htm#credits
http://www.aztecmuseum.ca/ads/index.htm#credits
In particular and insofar as the Apple //e, I should place added emphasis on
the importance of Phade Software's libraries:
AZTECPLUS by by BluPhoenyx (Mike T.) & MacProber
Aztec C65 3.2a
6-30-86
ReadMe
http://www.aztecmuseum.ca/docs/AztecPlus65.txt
Download
http://www.aztecmuseum.ca/AztecPlus65.zip
And oh yes, the AppleShell Project (lest we forget:)
ReadMe
http://www.aztecmuseum.ca/docs/AppleShell.txt
Download
http://www.aztecmuseum.ca/AppleShell.zip
And then of course we have CP/M 80 and the Softcard and Applicard and other
Z80 cards on the Apple II which provides yet another compiler track:
ReadMe
http://www.aztecmuseum.ca/docs/az80106d.txt
Download
http://www.aztecmuseum.ca/az80106d.zip
Manual
http://www.aztecmuseum.ca/docs/Aztec_C_1.06_User_Manual_Mar84.pdf
The Aztec C Museum still needs work but I completely revamped it recently
and hopefully it makes some more sense as a resource.
I also provide other resources for working with Apple II's and CP/M
The CPM 86 and CPM 80 Museum
This website is a Work In Progress of links and downloads dedicated to CP/M
(Control Program for Microcomputers) which was (and is) an operating system
similar to MS-DOS but which predated MS-DOS, and which is in fact the
operating system that MS-DOS descended from. But CP/M is much more than
simply an early version of MS-DOS and CP/M is very much alive in online
communities of Enthusiasts and Others who still use CP/M in Old (and
sometimes newer) Computers and Emulators. This website is maintained by Bill
Buckels as one of his several retro-computing sites which span several
decades of micro computing.
And even other compilers:
http://www.cpm8680.com/mix/index.htm
The other thing that I offer support for is Apple II graphics etc. through
the use of several utilities including:
http://www.aztecmuseum.ca/tools.htm
ReadMe
http://www.aztecmuseum.ca/docs/appletools.txt
Download
http://www.aztecmuseum.ca/appletools.zip
Have Fun! (I did and still am)
Bill Buckels
August 2009
John B. Matthews
<75988cab-f024-4985...@c14g2000yqm.googlegroups.com>,
datajerk <data...@gmail.com> wrote:
> On Aug 11, 6:23 pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
> > In article
> > <1f0f92e3-f832-4b32-9c51-6739cf4df...@q40g2000prh.googlegroups.com>,
> >
> > datajerk <dataj...@gmail.com> wrote:
> >
> > [...]
> >
> > > > Did anyone compare the code generated by Aztec with that from cc65?
> > > > I'm more concerned about the size than the speed.
> >
> > > I tried, but I could not get cc65 to compile my code. It errors with
> > > too many local variables. So I gave up. But I would like to compare
> > > the speed of my pi.c program. cc65 vs Aztec. mano-a-mano.
> >
> > <http://sense.net/~egan/apple2e_aztec_c/pi.c>
> >
> > $ cl65 -O2 --static-locals -t apple2enh pi.c
>
> Apparently I didn't try hard enough. Thanks for the tip. I too get
> a 12377 byte pi.
>
> I am having a few challenges running it however. I have been unable
> to use Ciderpress or AppleCommander to put this on a disk image and
> run it. However a2tools does work--DOS3.3 images only.
ProDOS keeps the start address and length as metadata, while cc65 (like
DOS) prepends it. AppleCommander has an option to sort it out [1].
Here's an excerpt from my Makefile:
PI = pi
${PI}: ${PI}.c
cl65 --static-locals -O -t apple2enh ${PI}.c
ac -d p1.po ${PI}
ac -cc65 p1.po ${PI} bin < ${PI}
> So now I have a DOS3.3 image with pi, when I BRUN PI I get screen
> garbage when the following code is run:
>
> printf("Start time: %s\n",asctime(localtime(&starttime)));
>
> This code works with any *NIX and Aztec C. My emulator has the
> Thunderclock card in slot 7. If I use the no-slot clock it also gets
> garbage. So I am unable to time this without using a wall-clock.
> Any ideas?
I get the same thing with %s, but %ju works. Of course, it only takes a
few seconds with Sweet16! :-)
[1]<http://sites.google.com/site/drjohnbmatthews/applecommander/acguide>
datajerk
> In article
Excellent thanks for the ac help. The %ju does clean up the screen
junk, however it is not reporting the system time. time() returns
-1. Does cc65 have support for getting the time from a //e? Google
has been little help.
Thanks.
John B. Matthews
<08a65be6-b51a-441a...@f33g2000vbm.googlegroups.com>,
datajerk <data...@gmail.com> wrote:
> On Aug 12, 10:01 am, "John B. Matthews" <nos...@nospam.invalid> wrote:
[...]
> > I get the same thing with %s, but %ju works. Of course, it only
> > takes a few seconds with Sweet16! :-)
>
> Excellent thanks for the ac help. The %ju does clean up the screen
> junk, however it is not reporting the system time. time() returns
> -1. Does cc65 have support for getting the time from a //e? Google
> has been little help.
Interestingly, this returns the time to the nearest minute:
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
int main (void) {
time_t starttime = time(NULL);
time_t endtime = time(NULL);
printf("Start time: %s\n",asctime(localtime(&starttime)));
printf(" End time: %s\n",asctime(localtime(&endtime)));
return EXIT_SUCCESS;
}
]-pi
Start time: Wed Aug 12 23:31:00 2009
End time: Wed Aug 12 23:31:00 2009
datajerk
> In article
> <08a65be6-b51a-441a-ba11-469f0bc42...@f33g2000vbm.googlegroups.com>,
Yep, that works for me too. If I remove:
__asm__ ("jsr %w", 0xc300);
From pi.c, then it works there too. Is there another or safer way to
set 80 columns with cc65?
Thanks again.
John B. Matthews
<b6e689bd-0614-4109...@b15g2000yqd.googlegroups.com>,
datajerk <data...@gmail.com> wrote:
[...]
> Yep, that works for me too. If I remove:
>
> __asm__ ("jsr %w", 0xc300);
>
> From pi.c, then it works there too. Is there another or safer way to
> set 80 columns with cc65?
IIUC, cc65 tries to make as few assumptions as possible about the
destination environment. If you know you're headed for Apple II, ProDOS
and Basic, this works by synchronizing the I/O hooks:
#include <conio.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
int main (void) {
time_t starttime = time(NULL);
time_t endtime = time(NULL);
/* Assume 80-column card, ProDOS, Basic */
__asm__ ("jsr %w", 0xc300);
__asm__ ("lda %b", 0x36);
__asm__ ("sta %w", 0xbe30);
__asm__ ("lda %b", 0x37);
__asm__ ("sta %w", 0xbe31);
__asm__ ("lda %b", 0x38);
__asm__ ("sta %w", 0xbe32);
__asm__ ("lda %b", 0x39);
__asm__ ("sta %w", 0xbe33);
/* Clear the screen, put cursor in upper left corner */
clrscr ();
printf("Start time: %s\n",asctime(localtime(&starttime)));
printf(" End time: %s\n",asctime(localtime(&endtime)));
return EXIT_SUCCESS;
}
Printing control-D PR#3 doesn't appear to work.
lyricalnanoha
On Thu, 13 Aug 2009, John B. Matthews wrote:
> IIUC, cc65 tries to make as few assumptions as possible about the
> destination environment.
Yeah.
> Printing control-D PR#3 doesn't appear to work.
That's because BASIC.SYSTEM (unlike DOS 3.3) traps this by tracing BASIC.
It can't do that in this case as it's not BASIC running.
-uso.
datajerk
> In article
> <b6e689bd-0614-4109-8326-ddca4a4f6...@b15g2000yqd.googlegroups.com>,
Not working with the //e. Can you send me the code for that?
> Printing control-D PR#3 doesn't appear to work.
My printer is on PR#1, is there a way I can just fopen the printer?
Thanks again. This really helps.
Michael J. Mahon
How about CR ctl-D PR#3?
-michael
NadaNet 3.0 for Apple II parallel computing!
Home page: http://home.comcast.net/~mjmahon/
"The wastebasket is our most important design
tool--and it's seriously underused."
John B. Matthews
"Michael J. Mahon" <mjm...@aol.com> wrote:
> John B. Matthews wrote:
[...]
> > Printing control-D PR#3 doesn't appear to work.
>
> How about CR ctl-D PR#3?
Good idea. That might work on DOS, as uso explained nearby, but it just
prints "PR#3" on ProDOS. There's a similar problem with the DOSCMD
($BE03) entry point when Basic isn't running.
John B. Matthews
<4976983e-eb79-4a06...@q14g2000vbi.googlegroups.com>,
datajerk <data...@gmail.com> wrote:
> On Aug 13, 11:21 am, "John B. Matthews" <nos...@nospam.invalid> wrote:
[...]
> > /* Assume 80-column card, ProDOS, Basic */
> > __asm__ ("jsr %w", 0xc300);
> > __asm__ ("lda %b", 0x36);
> > __asm__ ("sta %w", 0xbe30);
> > __asm__ ("lda %b", 0x37);
> > __asm__ ("sta %w", 0xbe31);
> > __asm__ ("lda %b", 0x38);
> > __asm__ ("sta %w", 0xbe32);
> > __asm__ ("lda %b", 0x39);
> > __asm__ ("sta %w", 0xbe33);
[...]
> Not working with the //e. Can you send me the code for that?
I ran this on Sweet16 2.1.1, ProDOS 2.0.3 (06-May-93), ROM 3 firmware.
> > Printing control-D PR#3 doesn't appear to work.
>
> My printer is on PR#1, is there a way I can just fopen the printer?
Unknown. I never tried.
> Thanks again. This really helps.
--
datajerk
> In article
> <4976983e-eb79-4a06-a061-0a15679f7...@q14g2000vbi.googlegroups.com>,
>
>
>
> datajerk <dataj...@gmail.com> wrote:
> > On Aug 13, 11:21 am, "John B. Matthews" <nos...@nospam.invalid> wrote:
> [...]
> > > /* Assume 80-column card, ProDOS, Basic */
> > > __asm__ ("jsr %w", 0xc300);
> > > __asm__ ("lda %b", 0x36);
> > > __asm__ ("sta %w", 0xbe30);
> > > __asm__ ("lda %b", 0x37);
> > > __asm__ ("sta %w", 0xbe31);
> > > __asm__ ("lda %b", 0x38);
> > > __asm__ ("sta %w", 0xbe32);
> > > __asm__ ("lda %b", 0x39);
> > > __asm__ ("sta %w", 0xbe33);
> [...]
> > Not working with the //e. Can you send me the code for that?
>
> I ran this on Sweet16 2.1.1, ProDOS 2.0.3 (06-May-93), ROM 3 firmware.
Still no love. I tried Sweet16 2.1.1, ProDOS8 2.0.3, ProDOS BASIC
1.5, ROM 3 firmware with the above/below code and I cannot access the
clock after col80 is setup. I get the same results on Virtual ]
[ emulating a //e. If I remove the Thunderclock card from Virtual ]
[ I get the same screen trash with or without col80.
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
void col80()
{
__asm__ ("jsr %w", 0xc300);
__asm__ ("lda %b", 0x36);
__asm__ ("sta %w", 0xbe30);
__asm__ ("lda %b", 0x37);
__asm__ ("sta %w", 0xbe31);
__asm__ ("lda %b", 0x38);
__asm__ ("sta %w", 0xbe32);
__asm__ ("lda %b", 0x39);
__asm__ ("sta %w", 0xbe33);
}
int main()
{
time_t starttime, endtime;
col80();
clrscr();
starttime=time(NULL);
printf("Start time: %s\n",asctime(localtime(&starttime)));
endtime=time(NULL);
printf("\nEnd time: %s\n",asctime(localtime(&endtime)));
exit(0);
}
I speculate that the above code some how hoses slot 7 (where the clock
card is).
jsr c300 with Aztec C does work and does not interfere with the clock
card. Perhaps a bug in cc65. I am out of ideas and permutations to
try.
Hint: The __asm__ code some how hoses basic 1.5. I have to reboot to
run a second test.
Thanks again for your help.
lyricalnanoha
On Thu, 13 Aug 2009, datajerk wrote:
> #include <stdio.h>
> #include <stdlib.h>
> #include <time.h>
>
> void col80()
> {
> __asm__ ("jsr %w", 0xc300);
> __asm__ ("lda %b", 0x36);
> __asm__ ("sta %w", 0xbe30);
> __asm__ ("lda %b", 0x37);
> __asm__ ("sta %w", 0xbe31);
> __asm__ ("lda %b", 0x38);
> __asm__ ("sta %w", 0xbe32);
> __asm__ ("lda %b", 0x39);
> __asm__ ("sta %w", 0xbe33);
> }
Shot in the dark here.
I wonder if this in a separate .s file and assembled with it would help.
.export _col80
_col80: jsr $C300
lda $36
sta $BE30
lda $37
sta $BE31
lda $38
sta $BE32
lda $39
sta $BE33
rts
It would still use the same prototype.
-uso.
datajerk
Thanks. Identical results as before.
mdj
> Thanks. Identical results as before.
If you're running under BASIC.SYSTEM you should be able to do a:
printf("\x04pr#3\n");
Which would be the equivalent of
PRINT CHR$(4) ; "PR#3"
in BASIC.
Just JSR'ing to $C300 will overwrite the KEYIN and CHAROUT vectors in
the zero page, which are redirected via the operating system when one
is installed. This will disconnect it, requiring a call to the re-
entry vector at $03D0.
Grab a copy of Beneath Apple ProDOS or the ProDOS TRM to see where the
vectors should be patched inside ProDOS.
Matt
lyricalnanoha
> On Aug 13, 10:10Â pm, lyricalnanoha
> <lyricalnan...@usotsuki.hoshinet.org> wrote:
>>
>> Shot in the dark here.
>>
>> I wonder if this in a separate .s file and assembled with it would help.
>>
>>       .export  _col80
>>
>> _col80:  jsr    $C300
>>       lda    $36
>>       sta    $BE30
>>       lda    $37
>>       sta    $BE31
>>       lda    $38
>>       sta    $BE32
>>       lda    $39
>>       sta    $BE33
>> Â Â Â Â Â Â rts
>>
>> It would still use the same prototype.
>>
>> -uso.
>
> Thanks. Identical results as before.
>
Tried. :( It was, admittedly, a shot in the dark.
-uso.
Bill Buckels
"datajerk" <data...@gmail.com> wrote:
>jsr c300 with Aztec C does work and does not interfere with the clockcard.
>Perhaps a bug in cc65. I am out of ideas and permutations to try.
Aztec C was written by extremely talented professionals and a relatively
widely used C compiler on the Apple II and Apple //e
When you are using something with less of a pedigree and proven track
recoird the degree of effort can be exhausting and all bugs are possible.
Drew
> > > I have a number of powermacs and OS 9 never seems reliable at reading/
> > > writing prodos disks (well 9.2.2). I find 8.6 on my Wallstreet works
> > > perfectly for reading and writing Prodos disks and when i had a
> > > powermac 7300 with 8.6 (gone now due to lack of space) that also
> > > worked well. Did 9 have issues or is there a why to make that work
> > > properly with Prodos? I tried formatting a 1.4mb floppy on my ibook g3
> > > with a USB floppy and it started to format then just hang :(
>
> > The problem with ProDOS disks on Macs is usually oriented about the
> > type of drive. 3.5" disks written in the newer, manual-inject 3.5"
> > drives used in later Macs (as opposed to the auto-inject drives that
> > grab the disk from you and pull it in) tend to write disks that don't
> > work reliably in Apple II drives.
>
> > Sheppy
>
> I'll admit I also have trouble copying Prodos disks with the Mac
> Finder, but me thinks that has to do with the driver in file
> exchange. I find that the "Bernie 2 the Rescue" emulator has way
> more success in copying files within the emulator than from the Mac
> Finder desktop.
>
> Rob
Using a USB floppy on ibook G3 Bernie was able to read/write files ok,
just for some reason wasn't able to format to disks..just said it was
write protected.
Drew
datajerk
> On Aug 14, 2:19 pm, datajerk <dataj...@gmail.com> wrote:
>
> > Thanks. Identical results as before.
>
> If you're running under BASIC.SYSTEM you should be able to do a:
>
> printf("\x04pr#3\n");
>
> Which would be the equivalent of
>
> PRINT CHR$(4) ; "PR#3"
Tried. It just puts "pr#3" on the screen. I created printpi.c to
read pi.txt and print, I then updated pi.c to output to a file
(pi.txt), so this works:
brun pi
pr#3
brun printpi
pr#0
delete pi.txt
Not ideal, but it works.
> Just JSR'ing to $C300 will overwrite the KEYIN and CHAROUT vectors in
> the zero page, which are redirected via the operating system when one
> is installed. This will disconnect it, requiring a call to the re-
> entry vector at $03D0.
>
> Grab a copy of Beneath Apple ProDOS or the ProDOS TRM to see where the
> vectors should be patched inside ProDOS.
Part of the attraction with C is not using assembly. :-) If this
were anything beyond a hobby, then yes I'd have to write the necessary
drivers to get col 80 and printing to work. I was assuming that
another had solved this problem. Clearly not a big deal.
datajerk
> "datajerk" <dataj...@gmail.com> wrote:
> >jsr c300 with Aztec C does work and does not interfere with the clockcard.
> >Perhaps a bug in cc65. I am out of ideas and permutations to try.
>
> Aztec C was written by extremely talented professionals and a relatively
> widely used C compiler on the Apple II and Apple //e
I'd argue that the cc65 team is equally as talented, just less focused
on a single platform. cc65 does produce faster and smaller code.
I'll published my results shortly.
> When you are using something with less of a pedigree and proven track
> recoird the degree of effort can be exhausting and all bugs are possible.
True, Aztec C was written for the Apple II by Apple II experts. It is
without question the most complete and advanced C for the Apple II
(IMHO of course).
John B. Matthews
<1af9176a-af61-4dc1...@d34g2000vbm.googlegroups.com>,
datajerk <data...@gmail.com> wrote:
> On Aug 13, 3:45 pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
> > I ran this on Sweet16 2.1.1, ProDOS 2.0.3 (06-May-93), ROM 3 firmware.
>
> Still no love. I tried Sweet16 2.1.1, ProDOS8 2.0.3, ProDOS BASIC
> 1.5, ROM 3 firmware with the above/below code and I cannot access the
> clock after col80 is setup. I get the same results on Virtual ][
> emulating a //e.
[...]
> I speculate that the above code some how hoses slot 7 (where the clock
> card is).
>
> jsr c300 with Aztec C does work and does not interfere with the clock
> card. Perhaps a bug in cc65. I am out of ideas and permutations to
> try.
>
> Hint: The __asm__ code some how hoses basic 1.5. I have to reboot to
> run a second test.
>
> Thanks again for your help.
I'm nonplussed. To obviate any effect from Basic 1.5 and my menu, I
built a boot disk with just ProDOS 2.0.3, loader.system from the the
"contrib" folder at <ftp://ftp.musoftware.de/pub/uz/cc65/>, and this
test code compiled with a recent build of cc65 V2.12.0:
<http://sites.google.com/site/trashgod/Home/p1.po>
#include <conio.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
/* Assume 80-column card, ProDOS, Basic */
void col80() {
__asm__ ("jsr %w", 0xc300);
__asm__ ("lda %b", 0x36);
__asm__ ("sta %w", 0xbe30);
__asm__ ("lda %b", 0x37);
__asm__ ("sta %w", 0xbe31);
__asm__ ("lda %b", 0x38);
__asm__ ("sta %w", 0xbe32);
__asm__ ("lda %b", 0x39);
__asm__ ("sta %w", 0xbe33);
}
int main (void) {
time_t starttime = time(NULL);
time_t endtime = time(NULL);
col80();
printf("Start time: %s\n",asctime(localtime(&starttime)));
printf(" End time: %s\n",asctime(localtime(&endtime)));
printf("Done! Press any key to exit.");
cgetc();
return EXIT_SUCCESS;
datajerk
> In article
> <1af9176a-af61-4dc1-8395-407c643f0...@d34g2000vbm.googlegroups.com>,
Loader.system. Thanks for the tip.
If you change:
time_t starttime = time(NULL);
time_t endtime = time(NULL);
col80();
to:
col80();
time_t starttime = time(NULL);
time_t endtime = time(NULL);
Then you'll see my problem. Once col80 is called, the time card
cannot be read. -1 is returned. basic.system and loader.system--same
results.
Thanks again.
John B. Matthews
<a6e69e75-0399-4b14...@g10g2000yqh.googlegroups.com>,
datajerk <data...@gmail.com> wrote:
[...]
> Loader.system. Thanks for the tip.
This is my favorite part:
; That's what it's all about !
lda #<MLI
ldx #>MLI
sta HIMEM
stx HIMEM + 1
> If you change:
>
> time_t starttime = time(NULL);
> time_t endtime = time(NULL);
> col80();
>
> to:
>
> col80();
> time_t starttime = time(NULL);
> time_t endtime = time(NULL);
>
> Then you'll see my problem. Once col80 is called, the time card
> cannot be read. -1 is returned. basic.system and
> loader.system--same results.
I compared assembler listings, generated with the -l option:
<http://www.cc65.org/doc/cl65-2.html>
In my example, pusheax (exported from lpush.s) saves the initialized
time before calling col80. In your code, decsp8 allocates the two stack
variables, then col80 is called before the times are initialized.
col80() probably needs to preserve some registers, but I don't know the
runtime well enough to suggest how.
An expedient approach might be to check the machine ID and initialize
the 80-column firmware in the loader, before the runtime gets started.
You wouldn't need to update the Basic global vectors; and you can exit
your code via $3D0, which is set up to invoke the ProDOS bye routine.
Alternatively, you could initialize the firmware in a Basic STARTUP
program that BRUNs the compiled object. Of course, that's what the
loader was designed to avoid. :-)
Michael J. Mahon
> On Aug 13, 10:49 pm, mdj <mdj....@gmail.com> wrote:
>> On Aug 14, 2:19 pm, datajerk <dataj...@gmail.com> wrote:
>>
>>> Thanks. Identical results as before.
>> If you're running under BASIC.SYSTEM you should be able to do a:
>>
>> printf("\x04pr#3\n");
>>
>> Which would be the equivalent of
>>
>> PRINT CHR$(4) ; "PR#3"
ProDOS likes the ctl-D to be the first character on a line,
that is, the first character after a CR. Try printing:
"\x0d\x04pr#3\n"
David Wilson
> datajerk wrote:
> > On Aug 13, 10:49 pm, mdj <mdj....@gmail.com> wrote:
> >> On Aug 14, 2:19 pm, datajerk <dataj...@gmail.com> wrote:
>
> >>> Thanks. Identical results as before.
> >> If you're running under BASIC.SYSTEM you should be able to do a:
>
> >> printf("\x04pr#3\n");
>
> >> Which would be the equivalent of
>
> >> PRINT CHR$(4) ; "PR#3"
>
> ProDOS likes the ctl-D to be the first character on a line,
> that is, the first character after a CR. Try printing:
> "\x0d\x04pr#3\n"
Isn't the CR EOT (ctrl-D) sequence the way Apple DOS recognises
commands while ProDOS detects the PRINT Applesoft token execution and
then looks for a control-D?
Shouldn't a C program running under BASIC.SYSTEM use the BE03 DOSCMD
vector to pass a command to BASIC.SYSTEM? See section A.3.1 of the P8
TRM.
Hmm, it says that this only works in deferred mode so you would need a
small BASIC program to run the C program.
datajerk
> In article
> <a6e69e75-0399-4b14-aaa5-604fa9b83...@g10g2000yqh.googlegroups.com>,
Thanks for all your help, but for now I am going to keep it simple.
Type PR#3, then BRUN.
Michael J. Mahon
> On Aug 15, 4:29 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
>> datajerk wrote:
>>> On Aug 13, 10:49 pm, mdj <mdj....@gmail.com> wrote:
>>>> On Aug 14, 2:19 pm, datajerk <dataj...@gmail.com> wrote:
>>>>> Thanks. Identical results as before.
>>>> If you're running under BASIC.SYSTEM you should be able to do a:
>>>> printf("\x04pr#3\n");
>>>> Which would be the equivalent of
>>>> PRINT CHR$(4) ; "PR#3"
>> ProDOS likes the ctl-D to be the first character on a line,
>> that is, the first character after a CR. Try printing:
>> "\x0d\x04pr#3\n"
>
> Isn't the CR EOT (ctrl-D) sequence the way Apple DOS recognises
> commands while ProDOS detects the PRINT Applesoft token execution and
> then looks for a control-D?
I couldn't remember for sure, so before posting, I ran a simple test
program:
100 PRINT " " CHR$(4)"CATALOG"
and it just printed " CATALOG". When I removed the " " from the
PRINT statement, it generated a catalog.
I then drew the incorrect inference that ctl-D had to be the first
character on a line to be effective.
So it seems that the rule is that ctl-D must be "the first character
output by a PRINT statement" for ProDOS to see it as a command.
Michael J. Mahon
Or, even simpler:
100 PRINT CHR$(4)"PR#3"
110 PRINT CHR$(4)"BRUN yourbinprogram"
and save it as STARTUP.
Then yourbinprogram will be run whenever the disk is booted or
"-startup" is typed.
If you don't want the automatic "startup" behavior, save the BASIC
program above as "yourprogram" and run it with "-yourprogram".