In article <23c2f1d0-d487-4f32-8837-45c9a8c87867n@googlegroups.com>,
I am Rob <gids.rs@sasktel.net> wrote:
>> I've updated KEGS, an Apple IIgs emulator for Mac OS X and Linux, to 1.19.
>> The Mac executable should run on 10.13 or later. It's also a universal app,
>
>Very Nice. Thank you so much for keeping the IIGS alive. I can confirm
>it still works under 10.13.
>
>Simply the best IIGS emulator out there. Compressing graphics with LZ4
>is so much fun at unlimited speed.
>
>First, if I may, I would like to make some requests to speed things up,
>then show what I have done, thanks to KEGS.
>
>I use the "Dump Text Screen" quite a bit. Can this be made into a
>hotkey? And can you make it copy to clipboard instead of to a file? I
>more often have an empty text window open to take notes, and is quicker
>to Copy/Paste, rather than have to navigate to find the Dump file.

KEGS 1.20 (when it is released) will have Copy. Press Ctrl-F9, and it will
copy the text screen to the clipboard. On a Mac, there also will be an
Edit->Copy_Text_Screen menu item you can select. Let me know if you are
on Linux, I probably need to do more testing there, Copy&Paste on X11 is
very complex.

>And secondly, I use the ESCape key to exit everything in my programming.
>If this doesn't cause too much confusion? Once one enters the
>Configuration Panel with F4, have ESC exit back to the previous screen
>immediately, and remove the "Exit Configuration" option, and have a 2nd
>press of the F4 key go to the "Save Changes to Config.kegs" for a choice
>to save the configuration. This will eliminate 1 keypress every time
>one goes into the Configuration Panel.

There is usually no need to manually "Save Changes to Config.kegs". Inserting
or ejecting disks automatically update it. But things changed by the
Function keys (like F5 to turn the status lines on and off) don't immediately
write to config.kegs. This is mostly for my personal convenience, since
changing the speed is not something I want to save to the config.kegs file
right away. I guess I could make the default setting to write a new
config.kegs on any state change, if you can explain a little bit why you
need it.

And F4 toggles the config panel on and off. So if you are on the disk
selection submenu, and press F4, you go back to the Apple IIgs, and if you
press F4 again, you go right to the disk selection submenu again.

>
>What has been done?
>
>I created a 2 gig disk image that works with SmartPort that allows 63
>volumes of 32 Mb in one slot. This works beautifully with Kegs.
>Instead of handling a ton of disk images, I wrote a block copier that
>copies any volume to a 2nd blank volume, which is needed to run S16
>files from. Currently there is no driver for GSOS to access any of the
>volumes other than the first volume and the driver I wrote for Prodos 8
>requires Basic.system to be in memory to access the other volumes.
>
>Which means, Prodos 8 system files and S16 files have to be run either
>from the first volume, which is where I keep the most used Prodos 8
>applications, or, from another empty slot volume. The first volume is
>set up to be a Boot volume into either Prodos 8 or GSOS and can launch
>the applications copied to the slot volume. A block copier makes short
>work of copying from a SmartPort volume to a slot volume.

I'll be honest, I don't fully understand what you've done. But if you think
it's useful, I recommend you make your code public, it might be useful
to others.

>This is what my ONLINE call looks like for the SmartPort volumes:
>
>Volumes:
>
>0:BOOT 1:DOCS 2:UTILS 3:APPS 4:STUFF
>5:BASIC.PGRMS 6:MUSIC 7:FONTS 8:WORK8 9:WORK9
>10:SOFTDISK 11:FORTH 12:PRINTSHOP 13:HTML 14:EAMON.ADV
>15:WORK15 16:WORK16 17:WORK17 18:WORK18 19:WORK19
>20:GAMES.BASIC 21:GAMES.BINARY 22:GAMES.DISKS 23:WORK23 24:WORK24
>25:WORK25 26:WORK26 27:WORK27 28:WORK28 29:WORK29
>30:WORK30 31:WORK31 32:WORK32 33:WORK33 34:WORK34
>35:WORK35 36:WORK36 37:WORK37 38:WORK38 39:WORK39
>40:WORK40 41:WORK41 42:WORK42 43:WORK43 44:WORK44
>45:WORK45 46:WORK46 47:WORK47 48:WORK48 49:WORK49
>50:SHR.APPS 51:SHR.APPS 52:SHR.GAMES 53:SHR.GAMES
>54:SHR.GAMES
>55:SHR.GRAPHICS 56:SHR.GRAPHICS 57:SHR.GRAPHICS
>58:SHR.GRAPHICS 59:GRAPHICS
>60:GRAPHICS 61:BAD.APPLE.MOV 62:LZ4.GRAPHICS
>
>/RAM/ /BOOT/ /MY.WORK/ /DEMO400/ /WORK/
>
>Type PREFIX,S4,Vx to set the Prefix of a SmartPort volume 0-62
>Type PREFIX /volname/ to set the Prefix of a regular volume
>
>
>... Notice how more than one SmartPort volume can have the same name.
>But the SmartPort volume that is set as the current volume in the
>SmartPort slot, cannot have the same name as one in an ordinary slot.
>One or the other has to be ejected first.
>
>I have also converted a lot of box art graphics to 320x400 mode and am
>in the process of creating a viewer to view directly to the VOC
>interlaced screen display. Currently this is a pain as all the 320x400
>graphics are in APF format, and the VOC demo disk has only one sample
>graphic that is split into 2 binary files of $8000 bytes each. The VOC
>demo works as expected though.
>
>Still have wishful thinking that you will do a 640x400x256 color mode
>for me yet. Even if it has to match the Second Sight card. Got my LZ4
>compressor working for SHR graphics and it compresses quite a bit better
>than APF, but is a bit slower at compression. Thus the unlimited speed
>is a big help. Due to the number of colors, complex graphics don't
>compress as much but I believe I can compress a fairly complex graphic
>by 50%. A graphic with areas of solid color, even more so. A full
>640x400x256 would take 256kb on disk, but could possibly get compressed
>down to 128kb or less.

I'm still thinking about this, but the palette is an annoyance, since trying
to support palette changes during screen drawing is a big complexity.
Would you find an 8-bit graphic mode without palettes useful: each byte
fully describes the final color: 3-bit Red, 3-bits Green, and 2-bits blue.
640x400 bytes fits in four 64KB banks.

Kent

> And F4 toggles the config panel on and off. So if you are on the disk
> selection submenu, and press F4, you go back to the Apple IIgs, and if you
> press F4 again, you go right to the disk selection submenu again.

I was using the Copy Screen selection quite a bit, which means I was pressing the sequence of: F4, ESC, up arrow, up arrow - rather than a whole bunch of down arrows. If Copy Screen gets put to a hot key, I won't need to enter the control panel very often. Thanks

>>I created a 2 gig disk image that works with SmartPort that allows 63
>>volumes of 32 Mb in one slot.

> I'll be honest, I don't fully understand what you've done. But if you think
> it's useful, I recommend you make your code public, it might be useful
> to others.

Normally Prodos only has a 16-bit word for access to 65536 blocks on a volume. Thus the limitation of only 32 Mb per disk image. Smartport gives me access to the third byte which gives me up to 256 * 65536 blocks, for a max size of 8 Gb in a disk image. Instead of using the 2 Gb (max 8 Gb) as one large volume, look at it as having 63 (max 256) volumes in one disk image. All that needs to be updated is the third byte to access each of the other volumes. I let the driver know which volume I want to access with use of the ,V parameter. The volume that is initiated gets treated as if it were the only volume on the device which the SmartPort is found to be in.

> >Type PREFIX,S4,Vx to set the Prefix of a SmartPort volume 0-62
> >Type PREFIX /volname/ to set the Prefix of a regular volume

> >I have also converted a lot of box art graphics to 320x400 mode and am
> >in the process of creating a viewer to view directly to the VOC
> >interlaced screen display. Currently this is a pain as all the 320x400
> >graphics are in APF format, and the VOC demo disk has only one sample
> >graphic that is split into 2 binary files of $8000 bytes each. The VOC
> >demo works as expected though.
> >
> >Still have wishful thinking that you will do a 640x400x256 color mode
> >for me yet. Even if it has to match the Second Sight card. Got my LZ4
> >compressor working for SHR graphics and it compresses quite a bit better
> >than APF, but is a bit slower at compression. Thus the unlimited speed
> >is a big help. Due to the number of colors, complex graphics don't
> >compress as much but I believe I can compress a fairly complex graphic
> >by 50%. A graphic with areas of solid color, even more so. A full
> >640x400x256 would take 256kb on disk, but could possibly get compressed
> >down to 128kb or less.

> I'm still thinking about this, but the palette is an annoyance, since trying
> to support palette changes during screen drawing is a big complexity.
> Would you find an 8-bit graphic mode without palettes useful: each byte
> fully describes the final color: 3-bit Red, 3-bits Green, and 2-bits blue..
> 640x400 bytes fits in four 64KB banks.

The 256 colors is pretty crucial so would need a full 8-bit color. I thought about it afterwards that I was still thinking in terms of how the IIGS would do it to get extra colors. But this no longer holds true when one has access to 256 colors, as this is no longer 16 colors per line but 256 colors per line. After thinking about this with more context, the palette does not need to be updated during screen drawing. Only one read from each palette in each bank is needed before drawing the 100 lines that each bank represents.

The order is just basically, read palette from first bank, draw its 100 lines, read palette from 2nd bank, draw its 100 lines, read palette from 3rd bank, draw its 100 lines, read palette from 4th bank, draw its 100 lines.
This will give each set of 100 lines its own palette or one can choose to copy the same palette to all 4 banks.

I also thought about how the luminescence part of the palette would work ($FF00.$FFFF). The idea would be able to quickly give the next gradient of a color in sequence, but for a max distance of 128 points in either direction.

For instance if:

Red = $B7, Blue = $78, Green = $34

a luminescence value of 0 uses Red = $B7, Blue = $78, Green = $34
a luminescence value of 1 uses Red = $B8, Blue = $79, Green = $35
a lumin value of 2 uses Red= $B9, Blue = $7A, Green = $36
etc...

a lumin value of $FF (-1) uses Red = $B6, Blue = $77, Green = $33
a lumin value of $FE (-2) uses Red = $B5, Blue = $76, Green = $32
etc...

And any time a color reaches 0 or $FF, then freeze that color at 0 or $FF and increase or decrease the other colors.

The palettes themselves would not need to be changed, just the luminescence value. If this sounds cool, by all means implement it. If not, I am ok with that too.

On 3/21/2023 4:21 AM, I am Rob wrote:
>> And F4 toggles the config panel on and off. So if you are on the disk
>> selection submenu, and press F4, you go back to the Apple IIgs, and if you
>> press F4 again, you go right to the disk selection submenu again.
>
> I was using the Copy Screen selection quite a bit, which means I was pressing the sequence of: F4, ESC, up arrow, up arrow - rather than a whole bunch of down arrows. If Copy Screen gets put to a hot key, I won't need to enter the control panel very often. Thanks
>
>
>>> I created a 2 gig disk image that works with SmartPort that allows 63
>>> volumes of 32 Mb in one slot.
>
>> I'll be honest, I don't fully understand what you've done. But if you think
>> it's useful, I recommend you make your code public, it might be useful
>> to others.
>
> Normally Prodos only has a 16-bit word for access to 65536 blocks on a volume. Thus the limitation of only 32 Mb per disk image. Smartport gives me access to the third byte which gives me up to 256 * 65536 blocks, for a max size of 8 Gb in a disk image. Instead of using the 2 Gb (max 8 Gb) as one large volume, look at it as having 63 (max 256) volumes in one disk image. All that needs to be updated is the third byte to access each of the other volumes. I let the driver know which volume I want to access with use of the ,V parameter. The volume that is initiated gets treated as if it were the only volume on the device which the SmartPort is found to be in.
>

Not that it matters for your project but just in case you didn't know,
Prodos doesn't quite have access to 65536 blocks but one block less than
that. The 16-bit word is not a zero based number but the actual number
of blocks accessible.

Charlie

<snip>

> > Normally Prodos only has a 16-bit word for access to 65536 blocks on a volume. Thus the limitation of only 32 Mb per disk image. Smartport gives me access to the third byte which gives me up to 256 * 65536 blocks, for a max size of 8 Gb in a disk image. Instead of using the 2 Gb (max 8 Gb) as one large volume, look at it as having 63 (max 256) volumes in one disk image.. All that needs to be updated is the third byte to access each of the other volumes. I let the driver know which volume I want to access with use of the ,V parameter. The volume that is initiated gets treated as if it were the only volume on the device which the SmartPort is found to be in.
> >
> Not that it matters for your project but just in case you didn't know,
> Prodos doesn't quite have access to 65536 blocks but one block less than
> that. The 16-bit word is not a zero based number but the actual number
> of blocks accessible.

Yes, I guess I knew that as 0 is a place holder for sparse files. It won't affect how many volumes can be accessed though as 0 is valid for a volume number.