Commodore 8296GD

classic Classic list List threaded Threaded
82 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: Commodore 8296GD

Steve Gray
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 <[hidden email]>
To: [hidden email]
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


Reply | Threaded
Open this post in threaded view
|

Re: Commodore 8296GD

Mike Naberezny
In reply to this post by Michał Pleban
Hi,

On 10/5/12 7:28 AM, Michał Pleban wrote:
> 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 :-)

That's what I thought also.

> 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.

Yes, I have them in PNG.  I don't think the list supports attachments so I'll
email them to you.

On 10/5/12 10:41 AM, Steve Gray wrote:
> 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.

It was not intended to be used for anything other than an initial test.

Regards,
Mike

--
Mike Naberezny ([hidden email]) http://6502.org

       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

Re: Commodore 8296GD

Steve Gray
I think I hurt Mike's feelings... sorry Mike. Not putting down your coding, just saying that the file format is inefficient. It worked great though for getting a picture on the screen, which is much more impressive than silly circles and lines ;-) Thanks for converting them. I'm sure when you get your HSG board working we'll see some much more impressive demos!
 
I am writing a two-pass symbolic disassembler for my CBMXfer, so will hopefully be able to disassemble and comment the code if anyone else is interested.
 
Steve

From: Mike Naberezny <[hidden email]>
To: [hidden email]
Sent: Friday, October 5, 2012 2:00:49 PM
Subject: Re: Commodore 8296GD

Hi,

On 10/5/12 7:28 AM, Michał Pleban wrote:
> 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 :-)

That's what I thought also.

> 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.

Yes, I have them in PNG.  I don't think the list supports attachments so I'll
email them to you.

On 10/5/12 10:41 AM, Steve Gray wrote:
> 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.

It was not intended to be used for anything other than an initial test.

Regards,
Mike

-- Mike Naberezny ([hidden email]) http://6502.org/

      Message was sent through the cbm-hackers mailing list


Reply | Threaded
Open this post in threaded view
|

Re: Commodore 8296GD

Marko Mäkelä
On Fri, Oct 05, 2012 at 11:25:55AM -0700, Steve Gray wrote:
>I am writing a two-pass symbolic disassembler for my CBMXfer, so will
>hopefully be able to disassemble and comment the code if anyone else is
>interested.

Have you tried existing disassemblers, such as the d65 which I wrote in
1994?

        Marko

       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

Re: Commodore 8296GD

Mike Naberezny
In reply to this post by Steve Gray
Hi Steve,

On 10/5/12 11:25 AM, Steve Gray wrote:
> I think I hurt Mike's feelings... sorry Mike.

Haha.  No you didn't.

> Not putting down your coding,
> just saying that the file format is inefficient.

It was just the simplest thing that would work.  I figured it would get thrown
away after the first couple of days of testing.  Apparently I was wrong.

> It worked great though for
> getting a picture on the screen, which is much more impressive than silly
> circles and lines ;-) Thanks for converting them.

We can certainly make it faster than it is now but it's always going to be
slow if we are using the drawing commands to plot bitmaps.  We really should
figure out how to write into the display memory on both the HSG and HRE.

Regards,
Mike

--
Mike Naberezny ([hidden email]) http://6502.org


       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

Re: Commodore 8296GD

Steve Gray
In reply to this post by Marko Mäkelä
Marko,
 
No, I have not tried any others. I already started before becoming aware of yours.
Its something I wanted to do myself and I want it to be windows based.
 
Steve

From: Marko Mäkelä <[hidden email]>
To: [hidden email]
Sent: Friday, October 5, 2012 2:51:25 PM
Subject: Re: Commodore 8296GD

On Fri, Oct 05, 2012 at 11:25:55AM -0700, Steve Gray wrote:
> I am writing a two-pass symbolic disassembler for my CBMXfer, so will hopefully be able to disassemble and comment the code if anyone else is interested.

Have you tried existing disassemblers, such as the d65 which I wrote in 1994?

    Marko

      Message was sent through the cbm-hackers mailing list


Reply | Threaded
Open this post in threaded view
|

RE: Commodore 8296GD

Baltissen, GJPAA (Ruud)
In reply to this post by Steve Gray
Hallo Steve,
 

> I am writing a two-pass symbolic disassembler for my CBMXfer,

I have a fast many-pass disassembler written in Turbo-Pascal. Open
source.


--
     ___
    / __|__
   / /  |_/     Groetjes, Ruud Baltissen
   \ \__|_\
    \___|       http://Ruud.C64.org


 


De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de
geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te
nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit
e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken.
Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige
overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij
overgebrachte virussen.

APG Algemene Pensioen Groep NV is gevestigd te Heerlen en is ingeschreven in het
handelsregister van de Kamer van Koophandel Limburg onder nummer 14099617


The information contained in this e-mail is confidential and may be privileged.
It may be read, copied and used only by the intended recipient.
If you have received it in error, please contact the sender immediately by
return e-mail; please delete in this case the e-mail and do not disclose its
contents to any person. We don't accept liability for any errors, omissions,
delays of receipt or viruses in the contents of this message which arise as a
result of e-mail transmission.

APG Algemene Pensioen Groep NV is registered in the trade register of the Chamber
of Commerce Limburg, The Netherlands, registration number: 14099617


       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

Re: Commodore 8296GD

Steve Gray
Hi,
 
I originally wrote a disassembler mid 80's for the CBM-II machines in BASIC. I used that as the starting point for the disassembler in CBMXfer, which is written in VB6. I have the two passes working and the symbols and data tables working. I need to fix a few bugs then work on making the output compatible with "something"... CC65, PAL, MAE??? not sure which. In the 80's I used PAL on the C64 to assemble my stuff. I don't expect the feature to be used too much in CBMXfer, but I write this stuff mostly because it fills my own needs.
 
Thanks for the heads up. I may take a look to see if I can get some other ideas.
 
Steve

From: "Baltissen, GJPAA (Ruud)" <[hidden email]>
To: [hidden email]
Sent: Saturday, October 6, 2012 2:30:38 AM
Subject: RE: Commodore 8296GD

Hallo Steve,


> I am writing a two-pass symbolic disassembler for my CBMXfer,

I have a fast many-pass disassembler written in Turbo-Pascal. Open
source.


--
    ___
    / __|__
  / /  |_/    Groetjes, Ruud Baltissen
  \ \__|_\
    \___|      http://ruud.c64.org/


 


De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de
geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te
nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit
e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken.
Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige
overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij
overgebrachte virussen.

APG Algemene Pensioen Groep NV is gevestigd te Heerlen en is ingeschreven in het
handelsregister van de Kamer van Koophandel Limburg onder nummer 14099617


The information contained in this e-mail is confidential and may be privileged.
It may be read, copied and used only by the intended recipient.
If you have received it in error, please contact the sender immediately by
return e-mail; please delete in this case the e-mail and do not disclose its
contents to any person. We don't accept liability for any errors, omissions,
delays of receipt or viruses in the contents of this message which arise as a
result of e-mail transmission.

APG Algemene Pensioen Groep NV is registered in the trade register of the Chamber
of Commerce Limburg, The Netherlands, registration number: 14099617


      Message was sent through the cbm-hackers mailing list


Reply | Threaded
Open this post in threaded view
|

Re: Commodore 8296GD

Michał Pleban
In reply to this post by Michał Pleban
Hello!

Today I checked the video memory orientation. It is really very simple.
The bitmap starts at $A000 in expansion ram, and continues to $DFFF.

The bitmap is organized linearly, so the first 64 bytes form the first
line, then the second line etc. This is different from, for example, C64
bitmap where the bitmap is formed into 8-byte "characters". Here the
data bytes are just placed line by line.

I have yet to figure out the correct way to switch on the display mode -
apparently the CRTC initialization sequence I found earlier is not
enough. I will keep looking in the ROM.

Regards,
Michau.

       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

Re: Commodore 8296GD

Michał Pleban

> I have yet to figure out the correct way to switch on the display mode -
> apparently the CRTC initialization sequence I found earlier is not
> enough. I will keep looking in the ROM.

OK, this is actually not true. I tried initializing the CRTC in a BASIC
program which gave me strange results. But when we perform directly a
SYS 35859 (which changes the five CRTC registers I wrote about before),
the graphics display is correctly turned on. So the suspicion was
correct - writing #$02 into CRTC register #$0C should turn on the
graphics display.

I think these are enough information to re-implement the HRE in VICE -
as it turns out, the board usage is pretty straightforward. I will try
to post ROMs on Zimmers later today.

Regards,
Michau.


       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

Re: Commodore 8296GD

Rainer
In reply to this post by Michał Pleban
Am Sat, 13 Oct 2012 12:54:52 +0200 schrieb Michał Pleban  
<[hidden email]>:

> Hello!
>
> Today I checked the video memory orientation. It is really very simple.
> The bitmap starts at $A000 in expansion ram, and continues to $DFFF.
>
> The bitmap is organized linearly, so the first 64 bytes form the first
> line, then the second line etc. This is different from, for example, C64
> bitmap where the bitmap is formed into 8-byte "characters". Here the
> data bytes are just placed line by line.
>
> I have yet to figure out the correct way to switch on the display mode -
> apparently the CRTC initialization sequence I found earlier is not
> enough. I will keep looking in the ROM.
>
> Regards,
> Michau.
>
>        Message was sent through the cbm-hackers mailing list

       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

Re: Commodore 8296GD

Rhialto
In reply to this post by Michał Pleban
On Sat 13 Oct 2012 at 13:06:03 +0200, Micha? Pleban wrote:
> OK, this is actually not true. I tried initializing the CRTC in a BASIC
> program which gave me strange results. But when we perform directly a
> SYS 35859 (which changes the five CRTC registers I wrote about before),
> the graphics display is correctly turned on. So the suspicion was
> correct - writing #$02 into CRTC register #$0C should turn on the
> graphics display.

I've done an implementation in VICE based on what we know so far.
Further hardware analysis will no doubt refine it. See below for a patch
that applies to a current VICE from the svn repository. I can't check
anything in yet, because VICE is in feature freeze due to a release,
Real Soon Now(tm).

I was wondering about the weird choice to enable the graphics by setting
the screen start address offset to $0200 (the register that is written
to contains the high byte). This doesn't even bring the start value
outside the normal range of screen addresses, so hi-res detection can't
work by observing the MA lines and triggering on an extra-high value.
It could only work by snooping writes to E880 and E881 both.

It occurred to me that the value ($02), as written, differs from the
normal value ($10) in another bit: the invert bit. In a 8296 this is
apparently not wired up like that; Just now looking at the schematics of
the board, on sheet 4 left-top I see that MA12 goes to a jumper (number
is unreadable) which is normally not connected, before going on into RAM
addressing. Another jumper (JU8, it seems) pulls the line to ground.
These presumably being the jumpers that go to the HRE board...

So, in fact, it seems more likely that the $10 bit controls the hi-res.
Why the screen start address is increased, I'm not sure yet, since in my
software version I need to subtract that offset again to ease my
calculations.

> I think these are enough information to re-implement the HRE in VICE -
> as it turns out, the board usage is pretty straightforward. I will try
> to post ROMs on Zimmers later today.

Thanks for sending me the ROMs directly, since they were not moved out
of the incoming directory yet. For people without the ROMs, here is a
little basic program that can test the HRE, without even switching out
of 80 column mode. This gives a slightly strange memory mapping but it
shouln't really hinder using the graphics.

 10 c = 59520 : rem crtc address
 20 poke c, 12: poke c+1, 2
 100 a=40960
 101 fori = a to a+2048: poke i,255: next
 110 for i = 0 to 512
 120 poke a+i,i and 255: poke a+i+1024,i and 255
 130 next
 300 for i = 0 to 9000: next
 310 poke c, 12: poke c+1, 16
ready.

(you can cut & paste that into VICE these days!)

And here is the diff:

http://www.falu.nl/~rhialto/vice-hre.diff
Run "xpet -model 8296 -pethre" and maybe with "-rom9 324992-02.bin -romA
324993-02.bin"

Switching on the hires prints some diagnostics, but just a limited
number of them. Not sure yet if I should worry about that.

-Olaf.
--
___ Olaf 'Rhialto' Seibert  -- There's no point being grown-up if you
\X/ rhialto/at/xs4all.nl    -- can't be childish sometimes. -The 4th Doctor

       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

Re: Commodore 8296GD

André Fachat
That is great news! Thanks for your work!

And I'm looking fwd to the next vice relrease "real soon"(tm) ;-)




Rhialto <[hidden email]> schrieb:
On Sat 13 Oct 2012 at 13:06:03 +0200, Micha? Pleban wrote:
OK, this is actually not true. I tried initializing the CRTC in a BASIC
program which gave me strange results. But when we perform directly a
SYS 35859 (which changes the five CRTC registers I wrote about before),
the graphics display is correctly turned on. So the suspicion was
correct - writing #$02 into CRTC register #$0C should turn on the
graphics display.

I've done an implementation in VICE based on what we know so far.
Further hardware analysis will no doubt refine it. See below for a patch
that applies to a current VICE from the svn repository. I can't check
anything in yet, because VICE is in feature freeze due to a release,
Real Soon Now(tm).

I was wondering about the weird choice to enable the graphics by setting
the screen start address offset to $0200 (the register that is written
to contains the high byte). This doesn't even bring the start value
outside the normal range of screen addresses, so hi-res detection can't
work by observing the MA lines and triggering on an extra-high value.
It could only work by snooping writes to E880 and E881 both.

It occurred to me that the value ($02), as written, differs from the
normal value ($10) in another bit: the invert bit. In a 8296 this is
apparently not wired up like that; Just now looking at the schematics of
the board, on sheet 4 left-top I see that MA12 goes to a jumper (number
is unreadable) which is normally not connected, before going on into RAM
addressing. Another jumper (JU8, it seems) pulls the line to ground.
These presumably being the jumpers that go to the HRE board...
So, in fact, it seems more likely that the $10 bit controls the hi-res.
Why the screen start address is increased, I'm not sure yet, since in my
software version I need to subtract that offset again to ease my
calculations.

I think these are enough information to re-implement the HRE in VICE -
as it turns out, the board usage is pretty straightforward. I will try
to post ROMs on Zimmers later today.

Thanks for sending me the ROMs directly, since they were not moved out
of the incoming directory yet. For people without the ROMs, here is a
little basic program that can test the HRE, without even switching out
of 80 column mode. This gives a slightly strange memory mapping but it
shouln't really hinder using the graphics.

10 c = 59520 : rem crtc address
20 poke c, 12: poke c+1, 2
100 a=40960
101 fori = a to a+2048: poke i,255: next
110 for i = 0 to 512
120 poke a+i,i and 255: poke a+i+1024,i and 255
130 next
300 for i = 0 to 9000: next
310 poke c, 12: poke c+1, 16
ready.

(you can cut & paste that into VICE these days!)

And here is the diff:

http://www.falu.nl/~rhialto/vice-hre.diff
Run "xpet -model 8296 -pethre" and maybe with "-rom9 324992-02.bin -romA
324993-02.bin"

Switching on the hires prints some diagnostics, but just a limited
number of them. Not sure yet if I should worry about that.

-Olaf.

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
Reply | Threaded
Open this post in threaded view
|

Re: Commodore 8296GD

Marko Mäkelä
In reply to this post by Rhialto
On Thu, Oct 18, 2012 at 08:59:14PM +0200, Rhialto wrote:
>(you can cut & paste that into VICE these days!)

Congratulations! The X11 port of CCS64 had that already in 1996 or
thereabouts. :-) Will copying from the VICE screen work too? :-)

        Marko

       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

Re: Commodore 8296GD

Rhialto
On Fri 19 Oct 2012 at 00:16:22 +0300, Marko Mäkelä wrote:
> On Thu, Oct 18, 2012 at 08:59:14PM +0200, Rhialto wrote:
> >(you can cut & paste that into VICE these days!)
>
> Congratulations! The X11 port of CCS64 had that already in 1996 or
> thereabouts. :-) Will copying from the VICE screen work too? :-)

Well, that's how I put it in my mail.
Actually I don't know how long the GTK version had it, I just copied the
feature into the Xaw version at some point when I noticed it.

-Olaf.
--
___ Olaf 'Rhialto' Seibert  -- There's no point being grown-up if you
\X/ rhialto/at/xs4all.nl    -- can't be childish sometimes. -The 4th Doctor

       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

Re: Commodore 8296GD

Mike Naberezny
In reply to this post by Rhialto
On 10/18/12 11:59 AM, Rhialto wrote:
> I can't check anything in yet, because VICE is in feature freeze due to a
> release, Real Soon Now(tm).

I am also looking forward to the release.  I hope it will include all your
work on the SuperPET 6809 mode emulation.

It has not been discussed on this list yet but Olaf recently implemented
emulation of the TPUG MMU board.  VICE is able to run Super-OS/9 now.

Regards,
Mike

--
Mike Naberezny ([hidden email]) http://6502.org

       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

Re: Commodore 8296GD

Groepaz
In reply to this post by Rhialto
On Friday 19 October 2012, you wrote:

> On Fri 19 Oct 2012 at 00:16:22 +0300, Marko Mäkelä wrote:
> > On Thu, Oct 18, 2012 at 08:59:14PM +0200, Rhialto wrote:
> > >(you can cut & paste that into VICE these days!)
> >
> > Congratulations! The X11 port of CCS64 had that already in 1996 or
> > thereabouts. :-) Will copying from the VICE screen work too? :-)
>
> Well, that's how I put it in my mail.
> Actually I don't know how long the GTK version had it, I just copied the
> feature into the Xaw version at some point when I noticed it.

i added it some time before 2.3 i think, not sure :)

--

http://www.hitmen-console.org    http://magicdisk.untergrund.net
http://www.pokefinder.org        http://ftp.pokefinder.org

Some electronic components are now so small that more time is spent looking
for them than using them.
<Arthur C. Clarke>


       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

Re: Commodore 8296GD

Michał Pleban
In reply to this post by Michał Pleban
Hello!

I am sorry for the delay - the board was already disassembled and packed
for sending to Steve, so I needed to dig it out. We have a long weekend
over here so I can play with my machines now :-)

Rhialto wrote:

> - Is the register at E888 write-only, or can you read it as well?

No, it's write-only. All reads always return $E8.

> - Does it seem to appear on multiple addresses, not only E888?

>From E888 to E88F, then from E898 to E89F, and so on until the end of
CRTC register space.

> - If the memory configuration goes to the setting with even the I/O
>   mapped out, is the E888 register still writable? It should be, to make
>   it possible to get ROMs and I/O back.

Apparently it might be possible to map the $E888 register out with some
values (see below).

>   Testing this is somewhat involved but should be possible, if you first
>   find out how the bits in E888 map to the jumpers (and in particular
>   /RAM ON, /RAM SEL 9 and /RAM SEL A). Then it needs a small ML program
>   to map in all RAM and then try to go back to normal.

I wrote a simple machine language program that pokes various values to
$E888 and tries to read from $9000, $A000, $B000 and $E800. It turns out
that some values hang the computer even when interrupts are switched
off, and the computer will not reset after that (it even doesn't beep),
so most probably they map out the $E888 register from writing so it
cannot be restored.

I did not see any significance of bits 3-6. Here are the results of the
read test (please note that I also tried reading from $F000 but it
always returns ROM):

0, 2, 8, 10:
$9000 - RAM, $A000 - RAM, $B000 - RAM, $E800 - RAM

1, 3, 9, 11:
$9000 - RAM, $A000 - RAM, $B000 - RAM, $E800 - I/O

4, 6, 12, 14:
$9000 - ROM, $A000 - ROM, $B000 - ROM, $E800 - RAM

5, 7, 13, 15:
$9000 - ROM, $A000 - ROM, $B000 - ROM, $E800 - I/O

128, 129, 136, 137:
hang

130, 138:
$9000 - RAM, $A000 - RAM, $B000 - RAM, $E800 - I/O

131, 139:
$9000 - RAM, $A000 - RAM, $B000 - RAM, $E800 - RAM

132, 140:
$9000 - RAM, $A000 - RAM, $B000 - ROM, $E800 - I/O

133, 141:
$9000 - ROM, $A000 - RAM, $B000 - ROM, $E800 - RAM

134, 142:
$9000 - RAM, $A000 - ROM, $B000 - ROM, $E800 - I/O

135, 143:
$9000 - ROM, $A000 - ROM, $B000 - ROM, $E800 - RAM

Apparently the bit #3 must have some meaning because it is different in
the values written to this register by the ROM, but I cannot figure out
what it does.

The writes must behave somewhat differently, because the ROM writes 131
to the register which maps I/O reads to RAM, yet the I/O register is
writable. Perhaps the bit #3 together with bit #7 controls write access
- this is yet to be determined.

One more thing - the register is not cleared by a reset. So if you map
out the BASIC ROM, then press the reset switch, the computer will not
restart because the BASIC ROM is still mapped out. Only switching it off
and on will work. Quite sloppy design, because resetting the computer
while performing some graphics operation may render it unusable unless
physically turned off (losing all RAM contents).

Regards,
Michau.

       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

Re: Commodore 8296GD

Rhialto
In reply to this post by Michał Pleban
Hi Michau,

On Thu 01 Nov 2012 at 11:36:42 +0100, Micha? Pleban wrote:
>
> Hello!
>
> I am sorry for the delay - the board was already disassembled and packed
> for sending to Steve, so I needed to dig it out. We have a long weekend
> over here so I can play with my machines now :-)

Thanks for your trouble!
Your measurements give interesting results... interesting in the sense
that they don't fit with my theories :-) I was hoping to map bits in
E888 to /RAM_ON, /RAMSEL_9 and /RAMSEL_A, but several of your results
don't fit with that, from the analysis I've done so far.

For instance, if I'm believing that table I posted in the list earlier,
the only case where the I/O area is replaced with RAM also has RAM at
$Fxxx. And you find that there is ROM there all the time.

Also, replacing the I/O by RAM is (in that same table) controlled by the
CR6 bit, and in the schematics I can't really seem to find a jumper that
that signal would go through.

It is also interesting that there are settings where the I/O space reads
as RAM, but the E888 register remains accessible to switch back, AND
also settings where it isn't.

So... this creates more questions really than it answers! I think we'll
need to wait for a schematic to be made, and some answers about what
signals it is actually attaching to...

> Rhialto wrote:
>
> > - Is the register at E888 write-only, or can you read it as well?
>
> No, it's write-only. All reads always return $E8.

Ok, this is something I can use in the emulation! (In fact it was
already that way).

> > - Does it seem to appear on multiple addresses, not only E888?
>
> >From E888 to E88F, then from E898 to E89F, and so on until the end of
> CRTC register space.

And this is also simple - on top of the selection for the CRTC (inside
the I/O space, bit 0080 is high, it simply checks for the 0008 bit to be
high too). Ea

> > - If the memory configuration goes to the setting with even the I/O
> >   mapped out, is the E888 register still writable? It should be, to make
> >   it possible to get ROMs and I/O back.
>
> Apparently it might be possible to map the $E888 register out with some
> values (see below).

Yes, and the interesting thing is that the area may be RAM, but some
mappings allow to write it again and go back, and others don't...


I'll be looking at your results some more, to see if I can make sense of
them :-)

> Regards,
> Michau.
Thanks a lot!
-Olaf.
--
___ Olaf 'Rhialto' Seibert  -- There's no point being grown-up if you
\X/ rhialto/at/xs4all.nl    -- can't be childish sometimes. -The 4th Doctor

       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

RE: Commodore 8296GD

Martin Hoffmann-Vetter
In reply to this post by Michał Pleban
Hello,

> I wrote a simple machine language program that pokes various values to
> $E888 and tries to read from $9000, $A000, $B000 and $E800. It turns
> out that some values hang the computer even when interrupts are
> switched off, and the computer will not reset after that (it even
> doesn't beep), so most probably they map out the $E888 register from
> writing so it cannot be restored.
>
> I did not see any significance of bits 3-6. Here are the results of
> the read test (please note that I also tried reading from $F000 but it
> always returns ROM):
>
> 0, 2, 8, 10:
> $9000 - RAM, $A000 - RAM, $B000 - RAM, $E800 - RAM
>
> 1, 3, 9, 11:
> $9000 - RAM, $A000 - RAM, $B000 - RAM, $E800 - I/O
>
> 4, 6, 12, 14:
> $9000 - ROM, $A000 - ROM, $B000 - ROM, $E800 - RAM
>
> 5, 7, 13, 15:
> $9000 - ROM, $A000 - ROM, $B000 - ROM, $E800 - I/O
>
> 128, 129, 136, 137:
> hang
>
> 130, 138:
> $9000 - RAM, $A000 - RAM, $B000 - RAM, $E800 - I/O
>
> 131, 139:
> $9000 - RAM, $A000 - RAM, $B000 - RAM, $E800 - RAM
>
> 132, 140:
> $9000 - RAM, $A000 - RAM, $B000 - ROM, $E800 - I/O
>
> 133, 141:
> $9000 - ROM, $A000 - RAM, $B000 - ROM, $E800 - RAM
>
> 134, 142:
> $9000 - RAM, $A000 - ROM, $B000 - ROM, $E800 - I/O
>
> 135, 143:
> $9000 - ROM, $A000 - ROM, $B000 - ROM, $E800 - RAM

At a look to the pcb photos a try to make a schematic. It's not complete, but the 74LS174 is an six bit register. On Bit is the select for the mux 74LS258. Four bits go to the input (b) of the four mux. The other input (a) come from the four jumper. I don't know the correct output, but this must be the cable to the jumper JU1 ... JU7 on the 8296 board. So i think this register are software controlled jumper JU1 ... JU7 (or better a subset).

> One more thing - the register is not cleared by a reset. So if you map
> out the BASIC ROM, then press the reset switch, the computer will not
> restart because the BASIC ROM is still mapped out. Only switching it
> off and on will work. Quite sloppy design, because resetting the
> computer while performing some graphics operation may render it
> unusable unless physically turned off (losing all RAM contents).

The register 74LS174 has a /CLR input at pin 1. I see a track near this pin. On the other end of this track is pin 2 (/RES) of 6545. So the question is, isn't that connected?

Martin


       Message was sent through the cbm-hackers mailing list
12345