Test suite for 6509 processor

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Test suite for 6509 processor

Michał Pleban
Hello!

I uploaded the first version of the 6509 test code to GitHub:

https://github.com/MichalPleban/6509-test

Right now the tests must be run in a real CBM-II machine, but in the
future they will be made standalone.

The "bin" directory contains the PRG file and a D80 disk image which can
be mounted in VICE. To run the tests type:

BLOAD "*" (this is BLOAD, not DLOAD!)
SYS 1024

The following features are tested so far:

* Reading and writing from/to another bank via LDA (zp),Y and STA (zp),Y
- also when crossing a page boundary.

* Reading memory using other (zp),Y instruction (which should NOT fetch
from another bank).

* Executing code in another bank.

* Reading back the value written to registers, using both normal
instructions and LDA (zp),Y.

At the moment I am not testing whether the value is actually written to
the RAM below $0000/$0001 registers. Since the 6509 CPU always reads
back the written value, it is not possible to know what is in the RAM
beneath it. To check the RAM, I will have to employ the 8088 CPU and
it's too late to do that today.

Regards,
Michau.



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

Re: Test suite for 6509 processor

MiaM
Den Sun, 25 Feb 2018 21:30:14 +0100 skrev Michał Pleban
<[hidden email]>:
> At the moment I am not testing whether the value is actually written
> to the RAM below $0000/$0001 registers. Since the 6509 CPU always
> reads back the written value, it is not possible to know what is in
> the RAM beneath it. To check the RAM, I will have to employ the 8088
> CPU and it's too late to do that today.

Or use indirect access to 0/1?

--
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.

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

Re: Test suite for 6509 processor

Michał Pleban
Hello!

Mia Magnusson wrote:

> Or use indirect access to 0/1?

This is already covered by the "read back" test - the 6509 reads back
the register value also on indirect access.

Regards,
Michau.



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

Re: Test suite for 6509 processor

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

Michał Pleban wrote:

> At the moment I am not testing whether the value is actually written to
> the RAM below $0000/$0001 registers. Since the 6509 CPU always reads
> back the written value, it is not possible to know what is in the RAM
> beneath it. To check the RAM, I will have to employ the 8088 CPU and
> it's too late to do that today.

OK, so I did test it :-) Writing a proper 8088 payload for the test
suite would take a whole night, but I examined the memory from the 8088
side by launching MS-DOS and running DEBUG.

Here's what happens:

* The 6509 DOES write data to memory when writing to registers $0000 and
$0001.

* The write occurs in the current execution bank (the one determined by
value of $0000 register). The KERNAL lives at bank $F only, so normally
these writes land in the internal SRAM and have no effect on anything.
However, if the code to be executed is placed in the DRAM, these writes
happen in the DRAM too and can be seen there by the 8088.

* The values being written are NOT what he CPU writes to these
registers, but rather what was left on the data bus from the previous
instruction. Therefore, if using simple STA $00 / STA $01 instructions,
value $00 will be written to $0000 and $01 to $0001, but if more
sophisticated instructions are used, other values may be placed there
(to be tested more thoroughly). That basically means that the 6509 CPU,
similarly to 6510, does not drive the data bus upon writing to these
registers, but it does drive the R/W signal.

Regards,
Michau.










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

Re: Test suite for 6509 processor

Michał Pleban
In reply to this post by MiaM
Mia Magnusson wrote:

> Or use indirect access to 0/1?

A side note - the fact that indirect access to these addresses will
still affect CPU registers is the reason why disk reads do not work
across 64 kB boundaries in the 6509 MS-DOS IPC library.

Interestingly, the IPC code contains specific workarounds in case the
read crosses such boundary (rewinding the memory pointer to 0000 and
incrementing the $1 register value) but they are worthless anyway
because as soon as anything is written to memory address $x0000,
everything goes out of the window. It is apparent that the programmers
who wrote this code did not understand fully how the 6509 works.

Regards,
Michau.




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

Re: Test suite for 6509 processor

MiaM
In reply to this post by Michał Pleban
Den Sun, 25 Feb 2018 23:19:51 +0100 skrev Michał Pleban
<[hidden email]>:

> Hello!
>
> Michał Pleban wrote:
>
> > At the moment I am not testing whether the value is actually
> > written to the RAM below $0000/$0001 registers. Since the 6509 CPU
> > always reads back the written value, it is not possible to know
> > what is in the RAM beneath it. To check the RAM, I will have to
> > employ the 8088 CPU and it's too late to do that today.
>
> OK, so I did test it :-) Writing a proper 8088 payload for the test
> suite would take a whole night, but I examined the memory from the
> 8088 side by launching MS-DOS and running DEBUG.
>
> Here's what happens:
>
> * The 6509 DOES write data to memory when writing to registers $0000
> and $0001.
>
> * The write occurs in the current execution bank (the one determined
> by value of $0000 register). The KERNAL lives at bank $F only, so
> normally these writes land in the internal SRAM and have no effect on
> anything. However, if the code to be executed is placed in the DRAM,
> these writes happen in the DRAM too and can be seen there by the 8088.

Godd! Now we know how the 6509 works. Do we want to emulate this
beahviour or would we rather have it not write to external memory (or
maybe always write to the same bank)? :)

> * The values being written are NOT what he CPU writes to these
> registers, but rather what was left on the data bus from the previous
> instruction.

I would had assumed previous cycle, not previous instruction, right?

> Therefore, if using simple STA $00 / STA $01 instructions, value $00
> will be written to $0000 and $01 to $0001, but if more sophisticated
> instructions are used, other values may be placed there (to be tested
> more thoroughly). That basically means that the 6509 CPU, similarly
> to 6510, does not drive the data bus upon writing to these registers,
> but it does drive the R/W signal.



--
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.

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

Re: Test suite for 6509 processor

MiaM
In reply to this post by Michał Pleban
Den Sun, 25 Feb 2018 23:41:57 +0100 skrev Michał Pleban
<[hidden email]>:

> Mia Magnusson wrote:
>
> > Or use indirect access to 0/1?
>
> A side note - the fact that indirect access to these addresses will
> still affect CPU registers is the reason why disk reads do not work
> across 64 kB boundaries in the 6509 MS-DOS IPC library.
>
> Interestingly, the IPC code contains specific workarounds in case the
> read crosses such boundary (rewinding the memory pointer to 0000 and
> incrementing the $1 register value) but they are worthless anyway
> because as soon as anything is written to memory address $x0000,
> everything goes out of the window. It is apparent that the programmers
> who wrote this code did not understand fully how the 6509 works.

If the IPC code is in bank 15, then the incorrect write would end up at
adress 0 and 1 in bank 15, which I assume is not a place where the 8088
wants to read/write from disk. So the 6509 IPC disk I/O code should
work even when crossing page boundaries.

P.S. does VICE emulate the 6509 behaviour correctly? Although there are
no 8088 emulation there, afaik it has a monitor making it possible to
check what happens anyways.

--
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.

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

Re: Test suite for 6509 processor

smf
On 25/02/2018 23:19, Mia Magnusson wrote:

> If the IPC code is in bank 15, then the incorrect write would end up at
> adress 0 and 1 in bank 15, which I assume is not a place where the 8088
> wants to read/write from disk. So the 6509 IPC disk I/O code should
> work even when crossing page boundaries.

 From my understanding of what has been said here:

Writing to 0 in any bank will cause the 6509 to start executing code in
another bank & there won't be any code there for it.

The value written to 0/1 in any bank doesn't end up in ram because the
cpu doesn't drive the data bus.

But maybe I'm wrong.


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

Re: Test suite for 6509 processor

smf
When I say any bank, I mean using the indirect instructions that let you
access data in a different bank.

It also sounds like it's impossible to read location 0/1 of any bank
that the 8088 card has written, because it will always come from the
bank switch registers.

On 26/02/2018 08:18, smf wrote:

> From my understanding of what has been said here:
>
> Writing to 0 in any bank will cause the 6509 to start executing code
> in another bank & there won't be any code there for it.
>
> The value written to 0/1 in any bank doesn't end up in ram because the
> cpu doesn't drive the data bus.
>
> But maybe I'm wrong.
>
>
>       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: Test suite for 6509 processor

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

Mia Magnusson wrote:

> Godd! Now we know how the 6509 works. Do we want to emulate this
> beahviour or would we rather have it not write to external memory (or
> maybe always write to the same bank)? :)

I can't imagine any code using this kind of functionality (it would
require the 8088 processor anyway) so we can safely omit it, and either
do not write anything, or write the actual data being written to the
register.

The only thing we cannot do is to write to the memory in another bank
than the current execution bank, because that would clobber the RAM.

> I would had assumed previous cycle, not previous instruction, right?

Yes, previous cycle of course.

Regards,
Michau.

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

Re: Test suite for 6509 processor

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

Mia Magnusson wrote:

> If the IPC code is in bank 15, then the incorrect write would end up at
> adress 0 and 1 in bank 15, which I assume is not a place where the 8088
> wants to read/write from disk. So the 6509 IPC disk I/O code should
> work even when crossing page boundaries.

Yes, but the write to address 0 also ends up in the CPU register, which
is the execution bank. So the CPU suddenly jumps to some random bank and
of course there is no valid code there, therefore it hangs.

> P.S. does VICE emulate the 6509 behaviour correctly? Although there are
> no 8088 emulation there, afaik it has a monitor making it possible to
> check what happens anyways.

All the tests I've written so far run in VICE correctly.

It's, however, not possible to peek into the memory at $x0000 and $x0001
with VICE's monitor because it always displays the CPU register there.
So it's hard to say what is actually getting written to the memory in
this case, and whether it even makes any sense to think of such writes.

Regards,
Michau.


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

Re: Test suite for 6509 processor

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

smf wrote:

> From my understanding of what has been said here:
>
> Writing to 0 in any bank will cause the 6509 to start executing code in
> another bank & there won't be any code there for it.

Yes.

> The value written to 0/1 in any bank doesn't end up in ram because the
> cpu doesn't drive the data bus.

Yes.

> When I say any bank, I mean using the indirect instructions that let you
> access data in a different bank.

One thing left to check is that when you are writing to 0/1 using
indirect instruction, does the CPU clobber memory in the execution bank
or in the bank chosen by register #1 (the latter would be more logical
IMHO)?

> It also sounds like it's impossible to read location 0/1 of any bank
> that the 8088 card has written, because it will always come from the
> bank switch registers.

Yes.

Regards,
Michau.

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

Re: Test suite for 6509 processor

smf
In reply to this post by Michał Pleban
On 26/02/2018 10:48, Michał Pleban wrote:

> I can't imagine any code using this kind of functionality (it would
> require the 8088 processor anyway) so we can safely omit it, and either
> do not write anything, or write the actual data being written to the
> register.

I would emulate the exact behaviour just so that people don't start
writing code that runs on the 6509 replacement, but doesn't run on the 6509.

Looking at the crazy ways people have used undocumented features on the
c64, I wouldn't put it past them having a greater imagination either.


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

Re: Test suite for 6509 processor

Groepaz
Am Montag, 26. Februar 2018, 21:18:29 CET schrieben Sie:

> On 26/02/2018 10:48, Michał Pleban wrote:
> > I can't imagine any code using this kind of functionality (it would
> > require the 8088 processor anyway) so we can safely omit it, and either
> > do not write anything, or write the actual data being written to the
> > register.
>
> I would emulate the exact behaviour just so that people don't start
> writing code that runs on the 6509 replacement, but doesn't run on the 6509.
>
> Looking at the crazy ways people have used undocumented features on the
> c64, I wouldn't put it past them having a greater imagination either.

from my experience with hacking VICE for a decade or so... i'm willing to bet
there indeed exists at least one program that relies on whatever odd
behaviour. chances are its a program where you'd least expect it :)

--

http://hitmen.eu                 http://ar.pokefinder.org
http://vice-emu.sourceforge.net  http://magicdisk.untergrund.net

The C65 was just a project to keep engineers busy while they tried to sell off
Commodore
<Bil Herd>



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

Re: Test suite for 6509 processor

Michał Pleban
[hidden email] wrote:

> from my experience with hacking VICE for a decade or so... i'm willing to bet
> there indeed exists at least one program that relies on whatever odd
> behaviour. chances are its a program where you'd least expect it :)

Well sure, when we speak about C64 where tens of thousands of programs
are written doing all kinds of inconceivable things.

But on a CBM-II which has very little software, and when the differences
in behaviour can only arise in a very specific interaction between 6509
and 8088 code, and nothing practical can be gained when exploiting it, I
don't think that's an issue.

Regards,
Michau.



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

Re: Test suite for 6509 processor

smf
On 27/02/2018 10:31, Michał Pleban wrote:
> But on a CBM-II which has very little software, and when the differences
> in behaviour can only arise in a very specific interaction between 6509
> and 8088 code, and nothing practical can be gained when exploiting it, I
> don't think that's an issue.

You're forgetting the p500, where there are similar inteactions with
location $0/$1 between the 6509 and vicII as the c64 has with the 6510
and vicII.

Plus if you make something work better than it does on a real 6509, then
new software will likely exploit it (either on purpose or by accident)
and you'll end up with compatibility issues.



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

Re: Test suite for 6509 processor

MiaM
In reply to this post by Michał Pleban
Den Mon, 26 Feb 2018 11:52:37 +0100 skrev Michał Pleban
<[hidden email]>:

> Hello!
>
> Mia Magnusson wrote:
>
> > If the IPC code is in bank 15, then the incorrect write would end
> > up at adress 0 and 1 in bank 15, which I assume is not a place
> > where the 8088 wants to read/write from disk. So the 6509 IPC disk
> > I/O code should work even when crossing page boundaries.
>
> Yes, but the write to address 0 also ends up in the CPU register,
> which is the execution bank. So the CPU suddenly jumps to some random
> bank and of course there is no valid code there, therefore it hangs.

Oh, now I get it.

Maybe it would be a good idea for a 6509 replacement to have some
mechanism to always force the code bank to $f.
 

> > P.S. does VICE emulate the 6509 behaviour correctly? Although there
> > are no 8088 emulation there, afaik it has a monitor making it
> > possible to check what happens anyways.
>
> All the tests I've written so far run in VICE correctly.
>
> It's, however, not possible to peek into the memory at $x0000 and
> $x0001 with VICE's monitor because it always displays the CPU
> register there. So it's hard to say what is actually getting written
> to the memory in this case, and whether it even makes any sense to
> think of such writes.

Oh.

You could use the P500 emulation in VICE and use VIC-II to display the
contents of $0/$1.

If this differs from real 6509 hardware, it might be one of the oddest
bug reports sent to the VICE people ;)

--
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.

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

Re: Test suite for 6509 processor

MiaM
In reply to this post by Michał Pleban
Den Tue, 27 Feb 2018 11:31:53 +0100 skrev Michał Pleban
<[hidden email]>:

> [hidden email] wrote:
>
> > from my experience with hacking VICE for a decade or so... i'm
> > willing to bet there indeed exists at least one program that relies
> > on whatever odd behaviour. chances are its a program where you'd
> > least expect it :)
>
> Well sure, when we speak about C64 where tens of thousands of programs
> are written doing all kinds of inconceivable things.
>
> But on a CBM-II which has very little software, and when the
> differences in behaviour can only arise in a very specific
> interaction between 6509 and 8088 code, and nothing practical can be
> gained when exploiting it, I don't think that's an issue.

Agree. This is also why I'm thinking about some kind of simplified
hardware emulation of the 6525's for a (hypothetical) CBM-II replica.
One of the two 6525's seems to only be used as three simple 8-bit I/O
ports while the other seems to be used as an interrupt controller and
two 8-bit I/O ports. It's just the interrupt controller that needs some
work to emulate, the rest seems to be easy to emulate with a bunch of
6821's (the cheapest hardware that is similar to and the grandparent to
the MOS PIO series, i.e.6522, 6525, 6526). If it's ok to ignore the
possibility of switching data direction and hard code each port for the
actual use in an CBM-II it might even be possible to emulate using
simple logic IC's (and maybe shadow ram for reading back what's written
to an output, depending on what's easiest to construct).

--
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.

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

Re: Test suite for 6509 processor

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

Mia Magnusson wrote:

> Maybe it would be a good idea for a 6509 replacement to have some
> mechanism to always force the code bank to $f.

Then programs compiled with cc65 would not work as they run in bank 1.

> You could use the P500 emulation in VICE and use VIC-II to display the
> contents of $0/$1.

I am not sure how good the P500 emulation in VICE is. It may be
interesting to test ;-)

> If this differs from real 6509 hardware, it might be one of the oddest
> bug reports sent to the VICE people ;)

I have some already pending regarding emulation of the CRTC in CBM-II,
you reminded me to submit them.

Regards,
Michau.



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

Re: Test suite for 6509 processor

smf
In reply to this post by MiaM
On 27/02/2018 12:27, Mia Magnusson wrote:

>
> Agree. This is also why I'm thinking about some kind of simplified
> hardware emulation of the 6525's for a (hypothetical) CBM-II replica.

A replica that doesn't replicate the hardware would be rather odd. If
you can't get the original chips then a CPLD or FPGA would be more
interesting.

I'm looking forward to https://ultimate64.com/Ultimate-64 as it should
be pretty easy to knock up a p500 or cbm2 core to run on it.



       Message was sent through the cbm-hackers mailing list
12