AppleWin Debugger Question - BSave Auxiliary Memory

[Bill Buckels]

Does anyone know how to bsave a region of auxiliary memory to disk from the
AppleWin Debugger...

BSave works fine BSaving MainMem but I can't seem to BSave from AuxMem...

With an DHGR image loaded at 0x2000, The BIN file BSaves flawlessly (Bank 0)
but adding 0xffff to 0x2000 to offset into Bank 1 at 0x2000 does not work
for me (likely because it is out of the adressable range).

Bill

[TomCh]

I checked the source code, and it only supports the main 64K. If you could raise a new feature request (although Berlios appears to be down at the moment) and I'll extend support for the aux 64K.

Tom

[Bill Buckels]

"TomCh" <tomchar...@blueyonder.co.uk> wrote:

> I checked the source code, and it only supports the main 64K. If you could
> raise a new feature request (although Berlios appears to be down at the
> moment) and I'll extend support for the aux 64K.

Thanks Tom. I had noticed that berlios is down, and I have only bits and
pieces of the latest code on my local computer which only includes the
debugger commands from the parser and Video.cpp which was a thoroughly
enjoyable read for me. So I have an excuse for failing to research further
on my own.

I skimmed alot of the other source and I have a deep appreciation of what
you and the other AppleWin developers have accomplished. Another thing that
really made the geek in me feel good was that the standard terminology of
AppleWin's graphics programmers (likely you) is the same as what I learned
in the late '80's when developing for the Everex680 (a Targa clone) in my
real job back then. Good Times Tom! Thanks for the memories...

I also didn't want to bother you nor interfere with other development that
is more important.

But as a modified command this would make it very easy for the user to
script for my current greedy purposes.

I realize that to do this for my purposes alone stretches the debugger out
of its original intent somewhat. I wonder what other justification I might
use for such a request...

I am not planning on expiring until I am at least 90 which is 30 years away
so I am sure to have time to enter this into a proper enhancement request
without all the chit-chat that I put into the one that I did last week.

Back to your Video code, the notes on the Windows Palette Collapse were
extremly helpful to me personally as well! What a discovery this must have
been! And I am not sure why you are setting rgbReserved in the 256 color
palette to 4, so you have given me lots to think about. Your method of
enumerating the palette is classic remapping and really easy to follow too.
Good code from what I have seen so far.

I could see you going to a 24 bit display at some point to render halftones
to represent pixel shifts. It would be easier for you. And to my way of
thinking this is the only way I know to sample analog properly. I have code
around here that does that that I wrote years back, but it is really fairly
trivial. I also understand that legacy support is important. What an
interesting read!

Back to this BSave stuff! Thanks for the positive response and taking the
time.

By contrast, I have yet to check what version of C++ you are using for
AppleWin. I don't mean this as a sleight, just proof that I am a little lazy
these days.

Bill

[sicklittlemonkey]

There should be project files for various versions of Visual Studio (Express).

Cheers,
Nick.

[Bill Buckels]

"sicklittlemonkey" <nick.w...@gmail.com> wrote;

> There should be project files for various versions of Visual Studio

I'm ok with Version 10 and I'll install SVN and get to work.

- BSave only works with main memory.

- Double Lo-Res colors have been completely botched since 1.17 and that's a
shame too... too bad this wan't tested.

- HGR screen grabs in 280 x 192 are missing detail... first orange pixel
missing...

- HGR mono is not accurate... color bit pattern is reversed on some
images...

Afew other little nits that bug me.

But I have no reason not to cut a little code and quit whining... because
AppleWin rocks!

I'll confine myself to video.cpp and talk to Tom some more after I do a
build or two... maybe he'll accept some changes...maybe he won't... at my
age I should be able to take no for answer anyway:)

Bill

PS - Problem as with everyone else is time of course...

[TomCh]

On Wednesday, 27 March 2013 23:00:48 UTC, Bill Buckels wrote:
> "sicklittlemonkey" wrote;

I replied in the berlios bug (#018944) about the DGR issue, but don't quite get the problem you are seeing. Maybe email me directly with some some screenshots of good vs broken? (btw. I xref'd with kegs32, a II GS emulator, and AppleWin looks similar - so I guess I'm missing something)

>HGR mono is not accurate
Can you send me more details or better, raise a new berlios bug for this?

btw. Thanks for the video.cpp patch (https://developer.berlios.de/bugs/?func=detailbug&bug_id=18928&group_id=6117): that got folded into the main-line.

Cheers,
Tom

[Bill Buckels]

"Bill Buckels" <bbuc...@mts.net> wrote:

>Double Lo-Res colors have been completely botched since 1.17 and that's a
>shame too... too bad this wan't tested.

I misled myself badly here... perhaps I should be tested. AppleWin's Double
Lo-Res Colors are working beautifully which I confirmed on my Apple II...
the wack of Double Lo-Res code and utilties that I wrote and tested with
AppleWin 1.16 failed miserably when I took the time to put my programs on a
disk and run them on the real thing. I am now kicking myself very hard for
testing only in an emulator.

I have almost finished rewriting everything Double Lo-Res that I have done
so it all actually works on a real machine as well as in AppleWin (since
1.17).

The other thing that I have again learned from all this is virtually nobody
(with possibly one or two exceptions, me for one) has used any of this (nor
likely will they) because surely they would have told me it doesn't work
correctly since this Double Lo-Res stuff of mine has been out there for the
last several years... but it could be much worse if my hobby was hardware...

Bill

[Bill Buckels]

"TomCh" <tomchar...@blueyonder.co.uk> wrote:

> I replied in the berlios bug (#018944) about the DGR issue, but don't
> quite get the problem you are seeing. Maybe email me directly with some
> some screenshots of good vs broken? (btw. I xref'd with kegs32, a II GS
> emulator, and AppleWin looks similar - so I guess I'm missing something)

I saw your reply and also cofirmed for myself that it is I and not AppleWin
that has a double lo-res bug, and requested the bug closed before I waste
more of your time. In retrospect I have Kegs here too and my GS as well...

>>HGR mono is not accurate
> Can you send me more details or better, raise a new berlios bug for this?

Before I do I want to build AppleWin here myself and see why the bit pattern
displayed in hgr mono reverses the orange and blue palette but not the green
and violet palette. This is hardly significant and shifting the pattern to
the right produces accurate results on orange and blue. Hardly signifcant as
I say...

> btw. Thanks for the video.cpp patch
> (https://developer.berlios.de/bugs/?func=detailbug&bug_id=18928&group_id=6117):
> that got folded into the main-line.

That was pretty minor too... but thanks for taking the time to include it
Tom. Back to my dungeon now while I still have some hours left to continue
my quest for double lo-res.

Bill

[Michael AppleWin Debugger Dev]

Hi Bill,

Mike O'Brien originally wrote the video code way back in ~95. The 8-bit palette code is "left-over" code from the Win95 days when clearing a 560x192 screen with 8-bits was significantly faster then 32-bit. A couple of years ago I've cleaned up the video code adding support for the half-pixel support so there may still be bugs lurking in it.

> - HGR mono is not accurate... color bit pattern is reversed on some
images...

Could you give a repro & usage test case on this please?

Thanks
Michael "AppleWin Debugger & misc. Video Dev"