DHGR Byte/Bit Editor

[Michael 'AppleWin Debugger Dev']

http://atariage.com/forums/topic/241626-double-hi-res-graphics/page-4
> Speaking of DHR drawing programs, there are only two I know of for the Apple II - 816 Paint and Dazzle Draw.
> One annoying thing is that neither of these programs lets you manipulate individual bits.

Not anymore! I've converted my HGR byte program over to DHGR.

Wanted to understand how DHGR works? This is an bit-editor to explore and examine how the bits make up colors in DHGR. Included is source, screenshots, examples, and a bootable (ProDOS) disk.

One innovated UI feature is that it shows HOW the DHGR bits are grouped to form a color.

For example, with the cursor on column 0:

[11]222 is shown.

This means that the first 4 bits are used to form the 1st pixel color, and the last 3 bits are used to form the 2nd pixel color. Pressing L to move the cursor right this is displayed:

2[33]44

Which means that this byte has the last bit for the 2nd pixel color, the entire 4 bits for the 3rd pixel, and the first two bits of the 4th color.

https://github.com/Michaelangel007/apple2_hgrbyte/

Cheers,
Michael

P.S.
Whoever wrote that "Squirt" File Manager -- Thank-You.
I've also included "Bitsy Bye" -- so don't complain about lack of options.
Pick your poison.

[I am Rob]

I hope you don't mind if I use your compliment about my "Squirt" program as an endorsement for my soon to be uploaded shareware software, Michael.

On the subject of double hi-res graphics, I have created a game creation package for the dbl-hi-res screen which features all of these routines:

- full screen color pixel editor locked into a 140x192 grid.
- fill routine which fills any complex shape and can fill any color to any of the other 16 colors within a closed area
- full screen color changer that changes any or all 16 colors to any or all other colors at the same time
- copy and paste to paste any shape multiple times
- shape capture which captures shapes to a shape table for drawing from applesoft or ML programs
- font capture to capture fonts from the dbl-hi-res screen in either block format or proportional font format
- draw routines to draw shapes from applesoft or ML programs
- draw routines to draw proportional fonts on the dbl-hi-res screen
- mouse routines to move a cursor on the dbl-hi-res screen
- screen convertors from hi-res to dbl-hi-res (hslf screen, full screen and full screen color match)
- screen convertor from dbl-hi-res to super hi-res (half screen or full screen)
- screen convertor from super hi-res to dbl-hi-res (any 140x192 area of the super hi-res screen)
- palette for super hi-res that matches dbl-hi-res colors.
- lz4 compressor for hi-res, dbl-hi-res and data
- lz4 compressor for super hi-res screen


This program has totally different draw routines to the dbl-hi-res screen than you will find by BeagleBros or Nibble magazine or anywhere else, and is about twice as fast as their routines. So no routines have been pirated from anyone else.

Not all routines will be included in the shareware version, and some routines will only be released after a certain number of shareware registrations have been met.

More to follow.

BTW Michael, it's Rob from Saskatchewan that is providing this great software :)

[Michael 'AppleWin Debugger Dev']

On Sunday, October 22, 2017 at 10:01:22 AM UTC-7, I am Rob wrote:
> I hope you don't mind if I use your compliment about my "Squirt" program as an endorsement for my soon to be uploaded shareware software, Michael.

Go ahead! I am extremely vocal about crappy software -- likewise when I find _good_ software I point that out too. Normally I hate file managers, but stuff like Norton Commander and Squirt are great examples of how to do it right.

I forgot if I asked in the past -- but is the source for Squirt available ? The reason I ask is because I wouldn't mind having a 40/80 column mode. Also, at some point I want to circle back and fix some of the fonts on the HDV version -- you'll probably want to include those fixes too.


Q. I noticed that DHGR images need $00 $20 at file offset $3FFE on disk (in memory $5FFE/$5FFF) for them to show up properly (as DHGR) with Squirt.

Is this a defacto standard? If so, where did it originate from ?

> On the subject of double hi-res graphics, I have created a game creation package for the dbl-hi-res screen which features all of these routines:
>
> - full screen color pixel editor locked into a 140x192 grid.
> - fill routine which fills any complex shape and can fill any color to any of the other 16 colors within a closed area
> - full screen color changer that changes any or all 16 colors to any or all other colors at the same time
> - copy and paste to paste any shape multiple times
> - shape capture which captures shapes to a shape table for drawing from applesoft or ML programs
> - font capture to capture fonts from the dbl-hi-res screen in either block format or proportional font format
> - draw routines to draw shapes from applesoft or ML programs
> - draw routines to draw proportional fonts on the dbl-hi-res screen
> - mouse routines to move a cursor on the dbl-hi-res screen
> - screen convertors from hi-res to dbl-hi-res (hslf screen, full screen and full screen color match)
> - screen convertor from dbl-hi-res to super hi-res (half screen or full screen)
> - screen convertor from super hi-res to dbl-hi-res (any 140x192 area of the super hi-res screen)
> - palette for super hi-res that matches dbl-hi-res colors.
> - lz4 compressor for hi-res, dbl-hi-res and data
> - lz4 compressor for super hi-res screen

Very, very nice!

Are you doing LZ4 compression on the Apple side?

> - shape capture which captures shapes to a shape table for drawing from applesoft or ML programs

I'll be extending DHGR.BYTE to "linearize" a user-defined region aka sprite extraction since that is needed on one of my projects.

What format are your shapes in ?

> This program has totally different draw routines to the dbl-hi-res screen than you will find by BeagleBros or Nibble magazine or anywhere else, and is about twice as fast as their routines. So no routines have been pirated from anyone else.

Any plans to release the source for paying customers?

> Not all routines will be included in the shareware version, and some routines will only be released after a certain number of shareware registrations have been met.

That makes sense.

> More to follow.

Looking forward to playing with that! Let me know when this is available -- you have your 1st customer. ;-)

> BTW Michael, it's Rob from Saskatchewan that is providing this great software :)

I grew up with and went to Asquith. Always nice to see another Canadian, eh? :-)

[Steve Nickolas]

On Sun, 22 Oct 2017, Michael 'AppleWin Debugger Dev' wrote:

> Go ahead! I am extremely vocal about crappy software -- likewise when I
> find _good_ software I point that out too. Normally I hate file
> managers, but stuff like Norton Commander and Squirt are great examples
> of how to do it right.

inb4 making an orthodox file manager (read: Norton Commander clone) for
ProDOS 8. xD

-uso.

[6502wo...@gmail.com]

Michael,

Nice work! Great to see more DHGR tools, especially a low level one like this.


-Mark

[I am Rob]

> I forgot if I asked in the past -- but is the source for Squirt available ? The reason I ask is because I wouldn't mind having a 40/80 column mode. Also, at some point I want to circle back and fix some of the fonts on the HDV version -- you'll probably want to include those fixes too.

Was it not on the disk you downloaded from Asimov? Thought I included it, but if not I can send you a copy.

Q. I noticed that DHGR images need $00 $20 at file offset $3FFE on disk (in memory $5FFE/$5FFF) for them to show up properly (as DHGR) with Squirt.

> Is this a defacto standard? If so, where did it originate from ?

No. Not a standard. I was playing around with the idea that the Aux memory part of the DHR screen should come after the Main part so then it would only require one move from $4000.5FFF to Aux memory area $2000.3FFF. I never really understood the reason for the Dazzle Draw method until I come across some possible uses that requires the AuxMem portion to be loaded first.

In Squirt, pressing Ctrl-A will swap the Aux and Main parts of the dhr screen, so if the picture looks out of whack when viewing a Dazzle Draw graphic, just press Ctrl-A.

> Are you doing LZ4 compression on the Apple side?

Yes. Compression is on the Apple. Using Sweet 16 at 100 Mhz takes approx 30 secs for single res and 75 secs for dhr. At 1 Mhz takes 75 minutes or more for dhr. It has a byte countdown that you can stare at for 75 minutes.

The super hi-res takes over 5 minutes to compress at 100 Mhz.

> > - shape capture which captures shapes to a shape table for drawing from applesoft or ML programs
>
> I'll be extending DHGR.BYTE to "linearize" a user-defined region aka sprite extraction since that is needed on one of my projects.
>
> What format are your shapes in ?

table is somewhat the same as hi-res shape table

table data

00.01 - # of shapes
02.03 - offset to first shape
04.05 - offset to end of shape table or offset to next shape in sequence
06.07 - either more offsets or start of shape data

shape data
byte #00 - width
byte #01 - height
byte #02 - # of shapes in animation sequence
byte #03.. - data for shape #1

when doing animation, the countdown of the width and height when drawing each shape determines where one shape ends and the other begins and all that need be known is the number of shapes included in the sequence.

I included the offset to the end of the shape table to make it so much easier to add shapes to the shape table that I felt it needed to be included, but it is not counted as part of the "# of shapes" counter.

> > This program has totally different draw routines to the dbl-hi-res screen than you will find by BeagleBros or Nibble magazine or anywhere else, and is about twice as fast as their routines. So no routines have been pirated from anyone else.
>
> Any plans to release the source for paying customers?

I might leave that as one of those "until a number of registrations is met" things before release. Most can make their own source, and the code is way easier to follow than the BBros method. But I may hand out to those who I deem a low risk of sharing or uploading. The software will be unprotected so need to cover some angles, and unfortunately not everyone is honest.

> > Not all routines will be included in the shareware version, and some routines will only be released after a certain number of shareware registrations have been met.
>
> That makes sense.

> I grew up with and went to Asquith. Always nice to see another Canadian, eh? :-)

Yeah! Saw that in another thread. You got relatives there to visit? We will have to meet up in Saskatoon and go for drinks sometime?

[Michael 'AppleWin Debugger Dev']

> I was playing around with the idea that the Aux memory part of the DHR screen should come after the Main part so then it would only require one move from $4000.5FFF to Aux memory area $2000.3FFF.

Yes, this is exactly what I thought so too!

> I never really understood the reason for the Dazzle Draw method until I come across some possible uses that requires the AuxMem portion to be loaded first.

I guess I'm (still) not (yet) buying the DazzleDraw reason ...

For everyone else's benefit, as you know there are two ways to store a DHGR in _linear_ memory (so it can be saved/loaded):

* Format: DazzleDraw: Aux part @ $2000, Main part @ $4000, requires two move: AUXMOVE, and MOVE
* Format: ???, Main part @ $2000, Aux part @ $4000, requires one move: AUXMOVE

I guess I don't understand the _other_ Pros and Cons for EACH way ?

Can you give any details for the advantage of the "backwards" way? Hell, what is it even called? :-)

For DHGR.BYTE there is an interesting hybrid approach I took. I cache the Aux mem at $4000 so I don't have to worry about reading from aux mem from a PC < $C000. =P

The dazzle draw format clutters things up:

On init:
; Interleave AUX/MAIN memory
; Copy MAIN $2000 -> AUX $2000
; Copy MAIN $4000 -> MAIN $2000
; Copy AUX $2000 -> MAIN $4000

On exit:
; "Unlinearize" interleaved AUX/MAIN memory
; so it can be saved in a linear format
; Copy MAIN $2000 -> MAIN $4000
; Copy AUX $2000 -> MAIN $2000


With the "reverse" way, init/exit

Forward init:
; Copy MAIN $4000 -> AUX $2000

Forward init:
; Copy AUX $2000 -> MAIN $4000

Oh well.

Is there is preferred

a) extension
b) ProDOS file type

for DHGR images? I've been appending ".DHGR" as a visual mnemonic but a file type would be good too.

Michael

[Michael 'AppleWin Debugger Dev']

> Was it not on the disk you downloaded from Asimov? Thought I included it, but if not I can send you a copy.

Ah-ha! It is in

/TXT.FILES/SQUIRT.SRC

Cool, thanks!

Q. This might be a dumb question but why are there some labels with "line numbers" ?

L1020, L1042, L1226

It almost looks like it was "reverse-engineered" with a automatic disassembly tool ? Any plans to convert these to human readable names?

One feature would to be to toggle showing lines numbers, and maybe line up scrolling.

> In Squirt, pressing Ctrl-A will swap the Aux and Main parts of the dhr screen, so if the picture looks out of whack when viewing a Dazzle Draw graphic, just press Ctrl-A

Good to know!

[Michael 'AppleWin Debugger Dev']

> Yes. Compression is on the Apple.

Oh wow, nice!

> Using Sweet 16 at 100 Mhz takes approx 30 secs for single res and 75 secs for dhr. At 1 Mhz takes 75 minutes or more for dhr.

Whoa! I guess the 'ol Apple 2 is pretty slow at stock speeds. At last at "full throttle" ~75 secs is tolerable.

> It has a byte countdown that you can stare at for 75 minutes.

LOL.

/voice="Comic Book Guy" worst. video. ever.

=P

[I am Rob]

> Q. This might be a dumb question but why are there some labels with "line numbers" ?
>
> L1020, L1042, L1226
>
> It almost looks like it was "reverse-engineered" with a automatic disassembly tool ? Any plans to convert these to human readable names?

No, well, maybe, sort of, reverse-engineered. I started the program in the monitor and copy/pasted the monitor listing from the text screen into TextEdit. Removed the hex bytes and any line number that was not needed and put an L in front of all branch addresses and copy/pasted the source back into the NFAssembler.

Some lucky line numbers got labeled, but probably got tired of creating meaningful labels.

Making source files from NFA is now so easy, I only use the monitor now to create the shortest of code.

[Michael 'AppleWin Debugger Dev']

Ah, OK, thanks for the clarification Rob. I'll probably add some human readable names at some point in the future. If I do, would you care for an email? :-)

Speaking of assemblers ...that's why I switched to Merlin32 -- less"bullshit" (turn-around-time) to go from (gVim) source to Apple 2 executable.
When I'm not auto-mounting files onto a .DSK image, I'm either using the debugger BLOAD "<bin>",<address> which can be automated via a script file.
Plus I have a custom hexdump8 utility that I can copy/paste into AppleWin's debugger.
e.g.
hexdump8 -@ 300 <file>

It probably wouldn't hurt to check out NFAssembler to see what directives it supports. You have a link handy?

Now to find a straight C/C++ utility to copy files onto a ProDOS .DSK image. (I haven't updated a2tools to understand ProDOS -- yet.)

[Michael J. Mahon]

Wasn't part of the plan that you could do a BLOAD, then BSAVE the AUXMEM
part to /RAM to display DHGR?

--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

[I am Rob]

> > I was playing around with the idea that the Aux memory part of the DHR screen should come after the Main part so then it would only require one move from $4000.5FFF to Aux memory area $2000.3FFF.
>
> Yes, this is exactly what I thought so too!
>
> > I never really understood the reason for the Dazzle Draw method until I come across some possible uses that requires the AuxMem portion to be loaded first.
>
> I guess I'm (still) not (yet) buying the DazzleDraw reason ...
>
> For everyone else's benefit, as you know there are two ways to store a DHGR in _linear_ memory (so it can be saved/loaded):
>
> * Format: DazzleDraw: Aux part @ $2000, Main part @ $4000, requires two move: AUXMOVE, and MOVE
> * Format: ???, Main part @ $2000, Aux part @ $4000, requires one move: AUXMOVE
>
> I guess I don't understand the _other_ Pros and Cons for EACH way ?
>
> Can you give any details for the advantage of the "backwards" way? Hell, what is it even called? :-)
>

The single move format which has the Main Memory part of the DHR screen saved first in a file on your hard drive means you can load the whole file ($4000) bytes all at once to memory from $2000 to $5FFF. All that would be required then is to move $4000.5FFF to Aux memory at $2000.3FFF, to view the DHR picture.

The Dazzle Draw format, which is considered the standard format, is saved on disk with the Aux Mem portion of the DHR picture saved first, followed by the Main memory portion all saved into a single file.

There really is no good reason for this layout, because as I was programming
the editor, I realized when the file was broken down into two hi-res screens and loaded one at a time, it did not matter if the AuxMem portion came first or the Main memory portion. One could have loaded the Auxmem portion from the 2nd half of the file just as easily as if it was in the first half.

But either way, when memory is tight due to a large program in memory, the large DHR file cannot be loaded all at once ($4000 bytes). So it is loaded as two separate parts of the hi-res screen. The AuxMem portion needs to be loaded first to Main Memory's hi-res area at $2000. Then moved over to AuxMem's graphic area to $2000. Then the Main Memory part of the file is loaded to Main Memory's hi-res area at $2000.

The only real time a double move is required is when the whole file is loaded into memory in one chunk, and the DHR file is saved in the Dazzle Draw format.


For anyone in the know, did the 16 kb apple computer only have one hi-res screen and the 2 hi-res screens were not available until the 32 kb machines were introduced?

[I am Rob]

On Sunday, October 22, 2017 at 4:02:49 PM UTC-6, Michael 'AppleWin Debugger Dev' wrote:
> Ah, OK, thanks for the clarification Rob. I'll probably add some human readable names at some point in the future. If I do, would you care for an email? :-)

I don't know. I have seen your labels and I don't really want to waste a day changing them to something more meaningful to me. ":)

> It probably wouldn't hurt to check out NFAssembler to see what directives it supports. You have a link handy?

http://www.ninjaforce.com/html/products.html

[I am Rob]

> Wasn't part of the plan that you could do a BLOAD, then BSAVE the AUXMEM
> part to /RAM to display DHGR?
>

I found you could do the same thing whether the AuxMem portion came first in the file or last in the file.

[Michael 'AppleWin Debugger Dev']

On Sunday, October 22, 2017 at 3:55:52 PM UTC-7, I am Rob wrote:
> On Sunday, October 22, 2017 at 4:02:49 PM UTC-6, Michael 'AppleWin Debugger Dev' wrote:
> > Ah, OK, thanks for the clarification Rob. I'll probably add some human readable names at some point in the future. If I do, would you care for an email? :-)
>
>
> I don't know. I have seen your labels and I don't really want to waste a day changing them to something more meaningful to me. ":)

Ha! Fair enough.

> > It probably wouldn't hurt to check out NFAssembler to see what directives it supports. You have a link handy?
> http://www.ninjaforce.com/html/products.html

Excellent thanks!

Looks like it has a sane set of directive -- Thank $Diety.
http://www.ninjaforce.com/html/products_nf_assembler_documentation.html

> NF Assembler / Editor needs at least 608K of extra memory.
Ah, guess it is IIgs only then. :-/

/Off-Topic: Ooooh, found this link on their page

Behind the scenes of an Apple IIGS demo
https://www.youtube.com/watch?v=glWIf0gfWSE

Fantastic stuff !

[Jorge]

On Monday, October 23, 2017 at 12:29:32 AM UTC+2, I am Rob wrote:
>
> For anyone in the know, did the 16 kb apple computer only have one hi-res screen and the 2 hi-res screens were not available until the 32 kb machines were introduced?

16k? LOL, no! That was too expensive and we didn't really know for sure if the "computer" we were buying was worth its price or a silly and expensive mistake, so 4 or 8k was what most of us started with. The promise was that we could upgrade at any time later from 4k to 8k, 12k, 16k, 20k, 24k, 32k, 36k or 48k.

Also, we had no Applesoft so there was no HGR, if you wanted HGR you had to do it in assembly.

The circuitry to display HGR1 and 2 was there of course, and it worked as long as you had memory intalled in the ranges mapped for HGR1/2. For example 16k had HGR1, but 12k could have it too if you left a gap of 4k from $1000 to $2000. 24k had only half of HGR2, etc. With the memory jumper blocks you made the tricks...

--
Jorge.

[I am Rob]

> The circuitry to display HGR1 and 2 was there of course, and it worked as long as you had memory intalled in the ranges mapped for HGR1/2. For example 16k had HGR1, but 12k could have it too if you left a gap of 4k from $1000 to $2000. 24k had only half of HGR2, etc. With the memory jumper blocks you made the tricks...
>
> --
> Jorge.

So the circuitry was also there for the softswitches?

If so, then I think Apple should have had some foresight to hardcode the graphics screen as well at $A000.BFFF and hi-res2 could have been under that at $8000.9FFF. That way the memory could have been contiguous above the text screen from $800..$9FFF for program space and viewable when memory became available. The graphics maybe could have been activated with a separate video memory much the same way that bank switching is done now. They mapped the $D000.FFFF space between 2 banks, why not the graphics screen as well? Program space could have been from $800.BFFF and the graphics screens on a separate bank mapped into $8000.BFFF. P:)

[inexora...@gmail.com]

On Sunday, October 22, 2017 at 3:29:32 PM UTC-7, I am Rob wrote:
> > > I was playing around with the idea that the Aux memory part of the DHR screen should come after the Main part so then it would only require one move from $4000.5FFF to Aux memory area $2000.3FFF.
> >
>

> But either way, when memory is tight due to a large program in memory, the large DHR file cannot be loaded all at once ($4000 bytes). So it is loaded as two separate parts of the hi-res screen. The AuxMem portion needs to be loaded first to Main Memory's hi-res area at $2000. Then moved over to AuxMem's graphic area to $2000. Then the Main Memory part of the file is loaded to Main Memory's hi-res area at $2000.

Why move at all?

Turn on 80STORE. Turn on HIRES. Turn on PAGE2. Load the first $2000 bytes of the file at $2000. Turn off PAGE2. Load the second $2000 bytes of the file at $2000. Done.

[I am Rob]

> > NF Assembler / Editor needs at least 608K of extra memory.
> Ah, guess it is IIgs only then. :-/

Not only that it is coded with 65816 instruction set.

[I am Rob]

I presume that is how Basic.system does it, but it has a buffer to copy from when changing banks.

A system program that taps directly into Prodos doesn't have that luxury.

[Michael 'AppleWin Debugger Dev']

On Sunday, October 22, 2017 at 4:09:18 PM UTC-7, Jorge wrote:

> 24k had only half of HGR2, etc. With the memory jumper blocks you made the tricks...

I wonder what was displayed in this case ... did the phantom RAM reads return 00 or FF ?

[I am Rob]

> I presume that is how Basic.system does it, but it has a buffer to copy from when changing banks.
>
> A system program that taps directly into Prodos doesn't have that luxury.

So basically, then hi-res page#1 from $2000.3FFF becomes the buffer to move to Aux memory.

[Jorge]

On Monday, October 23, 2017 at 1:39:55 AM UTC+2, I am Rob wrote:
> > The circuitry to display HGR1 and 2 was there of course, and it worked as long as you had memory intalled in the ranges mapped for HGR1/2. For example 16k had HGR1, but 12k could have it too if you left a gap of 4k from $1000 to $2000. 24k had only half of HGR2, etc. With the memory jumper blocks you made the tricks...
>

> So the circuitry was also there for the softswitches?

Yes, yes.

> If so, then I think Apple should have had some foresight to hardcode the graphics screen as well at $A000.BFFF and hi-res2 could have been under that at $8000.9FFF. That way the memory could have been contiguous above the text screen from $800..$9FFF for program space and viewable when memory became available. The graphics maybe could have been activated with a separate video memory much the same way that bank switching is done now. They mapped the $D000.FFFF space between 2 banks, why not the graphics screen as well? Program space could have been from $800.BFFF and the graphics screens on a separate bank mapped into $8000.BFFF. P:)

That would have required more chips and Woz was fixated in saving chips and gates like crazy. The genius is that with the bare minimum he pulled out an overall excellent design, sane machine, with lots of features. The PET was rubbish in comparison. And the TRS-80. But that had less chips to be fair.

--
Jorge.

[Jorge]

On Monday, October 23, 2017 at 1:51:27 AM UTC+2, Michael 'AppleWin Debugger Dev' wrote:
> On Sunday, October 22, 2017 at 4:09:18 PM UTC-7, Jorge wrote:
>
> > 24k had only half of HGR2, etc. With the memory jumper blocks you made the tricks...

Typo: it's 20k not 24k.

> I wonder what was displayed in this case ... did the phantom RAM reads return 00 or FF ?

I have no idea! But pulling out the second row of RAM chips anybody can try that.

--
Jorge.

[James Davis]

That is what I was thinking, too. But I had to leave for awhile. Long enough for you to get the softswitch method posted first.

[James Davis]

You CAN read from ROM while writing to RAM at the same addresses in high memory.

[I am Rob]

What are you talking about, James? Prodos is in the LC memory. The double hi-res graphics screen is in low memory. The double hi-res picture is on a hard drive. Please tell our readers how you plan on getting the picture from the hard drive using Prodos MLI calls. And what exactly are you copying from ROM?

[James Davis]

Not copying from ROM. Running Monitor Move Memory routines from within ROM while moving your half-pics in RAM after having bloaded them is what I was thinking. I don't know if you are banking the lower 48 and/or the upper 16 independently or not, but you can run monitor routines in ROM while writing to RAM, banks 1 or 2, high (12/16) or low (48), in all kinds of ways, using softswitches. You can even duplicate upper memory from ROM to RAM, so that you won't lose the code, stack, and zero page, you are running. I guess I am thinking too generally about this for you.

[Michael 'AppleWin Debugger Dev']

On Sunday, October 22, 2017 at 7:47:01 PM UTC-7, James Davis wrote:
> Not copying from ROM. Running Monitor Move Memory routines from within ROM while moving your half-pics in RAM after having bloaded them is what I was thinking. I don't know if you are banking the lower 48 and/or the upper 16 independently or not, but you can run monitor routines in ROM while writing to RAM, banks 1 or 2, high (12/16) or low (48), in all kinds of ways, using softswitches. You can even duplicate upper memory from ROM to RAM, so that you won't lose the code, stack, and zero page, you are running. I guess I am thinking too generally about this for you.

Uh, James, you DO realize that Rob knows how to use AUXMOVE = $C311, right ?

From: squirt.src

SEC ; copy from main to Aux
JSR $C311

[I am Rob]

What you just did is agree with the other person that a move routine is not needed, but answer with how a move routine would work in this situation. Are you reading the entire posts or are you skimming? This speed reading you are doing is throwing you off. Please go back and read the entire posts.

[I am Rob]

> Why move at all?
>
> Turn on 80STORE. Turn on HIRES. Turn on PAGE2. Load the first $2000 bytes of the file at $2000. Turn off PAGE2. Load the second $2000 bytes of the file at $2000. Done.

Ok! You got me thinking how Basic.system would do it and if it can do it, then I can do it. It is not quite as easy as you make it out, but almost.

80STORE doesn't need to be turned on if already in 80-col mode.
Before turning on PAGE2 for AuxMem, interrupts should be disabled.
And turned back on when finished. This is where there is one little catch. A disk error can occur when reading from disk and this can cause havoc with the banks out of whack. It was solved with a double PLP to return the interrupt status. One for the event of a disk error, and one for no disk error.

Also, after some testing it is good to note that SETMARK did not have to be set or be adjusted at midpoint which basically means that the B parameter that is normally used with Basic.system disk commands, is not needed for Prodos MLI commands. This was my biggest confusion, was thinking the B parameter needed to be set with the SETMARK command.

In the end, all is working and no move routines have to be used.

Thanks for forcing me to think this through.

[James Davis]

On Sunday, October 22, 2017 at 8:05:35 PM UTC-7, I am Rob wrote:
> What you just did is agree with the other person that a move routine is not needed, but answer with how a move routine would work in this situation. Are you reading the entire posts or are you skimming? This speed reading you are doing is throwing you off. Please go back and read the entire posts.

I am sorry if I upset you. The problem is that I started reading this thread early this morning, then when done switched to another thread, read it, then when done switched to another thread, read it, etc., etc., then returned to this thread when it had more to read, off and on all day, so I got a little confused.

[Tom Porter]

I'm very interested in a PLOT and SCRN routine for 16 color DHG (160 pix) mode... I have some basic code that does the same but having trouble translating it fully into asm... have done experiments with it and can now directly copy LORES and DoubleLORES into DHG... and have editing/picture tools... I think it would make great game development... you mentioned above Share-Ware... what is the price?

[Michael 'AppleWin Debugger Dev']

V.28 Updates:

* G to goto x,y. Space moves to next field; Enter accepts new x, or new x and y.
* Return toggles full screen
* Changed hotkey: Ctrl-G to center cursor
* Fix inverted aux/mem type for the cursor column
* Aux/mem shortened down to A/M
* Now shows normal and reverse bits for the saved byte