Trying to boot from a GS/OS 6.0.1 floppy... The welcome message is
shown briefly, for less than 1 sec, but after that a grid of pinkish
rectangles appear and constant clicking sound comes from the speaker.
Then it just stays that way.

Is it just a bad floppy or does this indicate a hardware problem?

I'm not flaming anyone but we should be aware that if there is not
enough traffic this group can vanish faster than a 6502-cycle.

OK - bad comparison but you get my point ;-)

Thanks for the attention!
Marcus

On Dec 24, 3:51 am, lyricalnanoha
usotsuki.hoshinet.org> wrote:

I created the Moon Patrol NIB and notes for it.

The data loaded is necessary unless you omit the moon base animation
(as all file versions do), so as Brendan and Antoine say you'll have
to find somewhere like the language card or aux mem to put it.
(Antoine is referring to the aux mem move routine at $C311).

Another option is to store the image data compressed in unused memory
and decompress it to the hires screen, thus keeping to the game's
original 48K spec. I was in the process of doing this some time ago,
but it was pushed on the back burner.

One problem is there isn't enough free memory to do that without
drawing to the displayed screen (or showing a messy data-filled
screen) unless you go beyond 48K.

Cheers,
Nick.

Ouch. Got wedged trying to pull this off, perhaps I'm interpreting the
hardware wrong. Looks like it's trying to write in bank 0 instead of bank
1. (I'm using the //e way to access bank 1, according to the docs I have,
rather than trying to go '816 and do it that way, as I don't yet
understand 65816 mode.)

The way I *wrote* the code, I meant it to leave ][+ space readable while
making //e space writable. (It doesn't seem to have done that.) Whether
I .org this high or low, it still gets wedged. (There's nothing
IIgs-dependent about the code beyond the C029 thing.)

I'm trying to create a memory environment conducive to plotting pixels in
320x200x16 mode. The palette approximates EGA.

-uso.

setty: lda $C029
ora #$80
sta $C029
bit $C005
ldy #32
@1: lda paltab-1, y
sta $9E00, y
...

"capknight" gmail.com> wrote in message
news:4510643d-e8e7-412c-9e85-eb2a8d058b24@f3g2000yqf.googlegroups.com...

Heh-heh!, kind of like saying, what a thrill,
driving on that old dirt road in our Model-T
again. ;-)

Bill Garber from GS-Electronics
http://www.garberstreet.com

"If you wish to forget anything on the
spot, make a note that this thing is to
be remembered." (Edgar Allen Poe)

On Dec 23, 2:50 pm, lyricalnanoha
usotsuki.hoshinet.org> wrote:

I've just gotten to thinking.

I don't know a lot about the IIgs under the hood, though I've kind-of
wondered how hard it would be to code for it. And maybe I'm being a bit
of a masochist here by wanting to do all of this without recourse to
GS/OS, but at least what I want to do is keep my DOS 3.3 comfort zone
(thank ghed for UniDOS and its ability to use the DOS 3.3 api on 3.5"
disks xD).

So I've been wondering about how hard it would be (keep in mind the only
tool I have for assembling 65816 code is CA65, though it seems that should
be adequate) to do some simple stuff. Like...

1. Good place to locate this stuff in RAM? I wouldn't want to step on
anything and I don't know the GS's memory map, though I'd need to load the
stuff into the "Contiguous 48" and then move it up... prolly isn't that
hard as 65816 is 6502 extended...

2. Set the 320x200 mode, (is it paletted? mb set it up with RGBI, the CGA
palette? would be more familiar for me) draw pixels on it, possibly write
on it in Shaston 8 (if not, I can always crack out a PC font), cursors
etc.

3. Set the 640x200 mode, same as above

I was testing a SCSI-IDE-CompactFlash setup for a different platform a
few weeks back. On a whim, I thought I'd bring out the Apple High
Speed SCSI card to test a similar setup on a IIgs. I used a SCSI-IDE
adapter, a cheap IDE-CF adapter, and a regular 128MB CF card.

http://picasaweb.google.com/simplepractices/Posts#5229593535780726082

System 6.0.1 boots fine from the first partition in my CF card -- this
was the same CF card taken from a working CFFA setup. It will not see
the other partitions in the CF card, since I think SCSI and IDE
partitions are set up differently. And I didn't want to re-format my
CF card because I still use it with my CFFA.

I wasn't planning on any wiring or soldering work, so I had to use an
external SCSI case to hook up the adapters. The adapters use regular
molex connectors for power (IIRC, Henry used to sell/modify IIgs power
supplies to provide additional connectors). The other platform (NeXT)
I was working on already had this molex connector. The SCSI-IDE
adapter has a regular 50-pin SCSI connector.

http://cgi.ebay.com/3-5-Disk-Superdrive-Controller-Card-Apple-IIe-
IIgs_W0QQitemZ200255283191QQihZ010QQcategoryZ51046QQssPageNameZWDVWQQrdZ1QQcmd
ZViewItem

Anyone need a superdrive controler for $450?

-- Charlie Springer

I am working on file compression. I mentioned in a previous thread
that I did better than others. I was wrong. The experiment was
blotted by a bug. Now I'm getting results about as good as PKWare's
deflate/maximum technique. I still have ideas. Again, it may be due
to an error. Again, as mentioned previously, it is very slow. I have
in mind some techniques to speed up the compression. They wouldn't be
that good:

* Store the first 16 or 32 matches for the last 16 words in the
input that are compressible by lz77 (shortening blocks that have
occured before to the location and length of such comparison). If a
hit occurs, simply compare it to the first matches and scan from the
last match on if full.

* Store the last 16 or 32 non-matches. Scan these for the current
input first, and if found, check it for a match to current and remove
the entry.

Again, I don't think these would help much. In fact, on poorly
compressible files, it may take longer. I am looking for other
techniques to speed up this technique. I assume I must minimize the
hits. Any help would be appreciated.