Re: Commodore 8296GD

Hi,
 
I don't remember writing any of the demos for 512x512 unless I mixed up the x/y or was just trying different things.
I said "the ability to re-define..." not that I did do that, or even wrote them "properly" ;-)
I did see the screen-dump utility, and it is able to read the memory but setting x/y and calling a function. The GDP chip then halts processing to read the pixel. You are still going throw the chip. I couldn't find any equivilent WRITE function. Still, more testing is definitely needed.

I did not generate those image files.. Mike Naberezny did and sent them to me. They are extremely inefficient, and I was working on a RLE compression version but never finished. When pixel plotting proved to be so slow I decided to concentrate on disassembling the rom to figure out direct access to memory, and that's where I am now. Perhaps you can send me your HRE programs and I can test them on the HSG board.
 
For HRE, it should be simple enough to write a series of bytes directly to video memory and see what comes out. Try writing 16 consecutive $0B bytes starting at $A000. That will tell you if the memory is organized by block, or row. $0B will let you see what order the pixels are sent out  (11010000 or 00001011). You could then try writing every 16th byte. Then try groups of 64 bytes $FF then 64 bytes $00 to see if you get alternate horizontal lines etc.
 
I think I have the CBM-II image I could send you.
 
Steve
 

>________________________________
> From: Michał Pleban <lists@michau.name>
>To: cbm-hackers@musoftware.de 
>Sent: Friday, October 5, 2012 10:28:35 AM
>Subject: Re: Commodore 8296GD
>  
>Hello!
>
>Steve Gray wrote:
>
>> Thanks for testing! That's good to hear that the basic extensions/tokens
>> are the same. Of course, I only had the 512 x 256 pixel version at the
>> time when I did that. I now have a 512x512 version as well.
>
>Now that's strange, because demo #3 is written for 512x512 ;-)
>
>> One of the neat things about the HSG board is the ability to re-define
>> the screen co-ordinate system, so theoretically the software should work
>> on either if written properly.
>
>It will not, because you are using IPLOT in your demos which use
>absolute coordinates :-P
>
>> Ya, since there is NO access to the display ram, the image viewer is
>> EXTREMELY slow. If you look at the code there's like 3 commands to draw
>> each pixel. It does take about 20 minutes for the complete screen.
>> Sadly there is no pixel PLOT or PSET command. I didn't spend a lot of
>> time on the Etch-a-sketch ;-)
>
>Yes, I noticed :-) For my image viewer, I used a simple "compression"
>scheme where the software tries to draw as long vertical lines as
>possible. So if there is a long row of pixels on a line, it is converted
>to a single IPLOT command (and vice versa for black pixels). It works
>very well for simple images (like the Commodore logo), it is hovewer
>still an overkill for dithered photos or dot patterns (like the
>Macintosh desktop picture).
>
>> I tried disassembling the ROM to see if there was a way to access the
>> memory somehow but couldn't find anything, although I never completely
>> understood the code (not enough time).
>
>There should be a way to access it (at least to read it) because there
>is a command to print the screen in an IEEE printer. It must be in the
>ROM somewhere :-)
>
>Now with HRE it will be much easier, the pixel data is at $A000 so you
>just need to write a small routine to access it (ROM must be banked out
>and so the interrupts must be disabled).
>
>Which brings a question - do you possibly have PNG or BMP versions of
>the images you are using in your demos? I would like to display them on
>the screen, do a memory dump of the bitmap and compare - this would tell
>me everything about how the bitmap is organized in RAM.
>
>Regards,
>Michau.
>
>
>
>
>       Message was sent through the cbm-hackers mailing list
>
>
>   

       Message was sent through the cbm-hackers mailing list