BLOAD'ing DHR pictures fail from Smartport Hard Drive

4 posts / 0 new
Last post
Offline
Last seen: 6 years 6 months ago
Joined: Sep 19 2017 - 01:05
Posts: 2
BLOAD'ing DHR pictures fail from Smartport Hard Drive

Hello,

I have a Floppy Emu and copied all of my basic programs to a Smarport hard drive image. Whenever I try to use the auxiliary memory during the process of loading half of a DHR image, the Apple IIc does not know that there is a smartport hard drive connected. This happens when I use POKE 49237,0. The very next step is to BLOAD that half of the image file but it tries to read it from the internal floppy drive. If I issue a "PREFIX,S5,D1" command from within the program at that point, I get the message NO DEVICE CONNECTED. I can issue POKE 49236,0 and BLOAD the other half of the image just fine.

The issue seems to be that the AUX memory has no clue that there is a smartport hard drive attached. Does anyone have any suggestions? I am thinking I can POKE the AUX memory somewhere to tell it I have a hard drive attached, but I don't know where in memory this may be. The other option is to do all of the BLOADing to the main memory and write a routine to copy the data to AUX memory after it is BLOADed then BLOAD the other half to main memory.

Thanks for your help,
Mike

Offline
Last seen: 1 year 6 months ago
Joined: May 27 2013 - 13:01
Posts: 849
Re: BLOAD'ing DHR pictures fail from Smartport Hard Drive

I have never heard of those commands to get the computer to show images.

The one I remember is from the program, "flying colors" and I remember the command being--->

CALL - 3100 : POKE - 16302,0

speedyG's picture
Offline
Last seen: 4 years 10 months ago
Joined: Nov 16 2011 - 07:45
Posts: 2493
Re: BLOAD'ing DHR pictures fail from Smartport Hard Drive

hello thorr
and welcome to the community:
please bear in mind the the Apple //e stores the content of the DoubleHires pages in 2 different RAM Areas !
so there are several steps needed to display that kind of graphics !
load 1 part of the graphics to the one area of RAM
and second load the alternete interleaving rest of the graphics to the second RAM area.
Then set the correct softswitches
and finally activating the display.....
Here is a small programm to test it and become familiar with the required routines:
http://www.appleii-box.de/G74UltraFastPix.htm
besides the are at my site several additinal pages about that topic:
http://www.appleii-box.de/
starting with the links to page G01 till G93... most of them in english....
aincerely
speedyG

Offline
Last seen: 6 years 6 months ago
Joined: Sep 19 2017 - 01:05
Posts: 2
Re: BLOAD'ing DHR pictures fail from Smartport Hard Drive

Thanks everyone. I am not sure if what I am asking is clear or not. I know how to load double hi-res graphics, etc. The programs work fine on floppy disks. When I copy those programs to a Smartport hard drive, they fail because they try to read from the floppy disk when bloading the AUX memory half of the double hires file.

I was also working on this problem on the atariage forum and a member helped to write assembly code to get around the problem but not solve it directly: http://atariage.com/forums/topic/270126-how-to-use-paths-on-smartport-hard-drive-within-programs/

Basically, it loads the entire image (both main and aux halves) to main memory from the hard drive then copies half of it to aux memory after it is loaded. This way there is no disk access during the aux memory portion.

A better solution would be to figure out how to tell the computer that there is a hard drive attached while in AUX memory. The computer forgets that it is attached for some reason as soon as I do a POKE 49237,0. As soon as I poke it back to main memory with POKE 49236,0 the hard drive is "there" again. It's a strange problem. If anyone has a smartport hard drive, it would be interesting to know if they run into the same problem when trying to bload double hires images. Somewhere in memory, the Apple II knows what drives are attached. I want to update this memory manually so it can find the hard drive while in AUX memory.

Thanks!
Mike

Log in or register to post comments