New System 9 and 11 Test ROM

[beaver]

Greetings all. I wish you a good Spring 2021. Recently I started learning to program the 6802 in assembly and decided to write my own test ROM, and added some improvements to Leon's ROMs. I have made the source and hex files available here:
https://edcheung.com/album/album21/asm/asm.htm

I hope others will come up with ideas for improvement and let me know so I can add them, or add these themselves.

Dr Edward Cheung (edcheung.com)
CARGPB26

[John Robertson]

Post by beaver
https://edcheung.com/album/album21/asm/asm.htm
I hope others will come up with ideas for improvement and let me know so I can add them, or add these themselves.
Dr Edward Cheung (edcheung.com)
CARGPB26

Hi Ed,

Great news carrying on Leon's work!

If you are looking for suggestions I've always liked the idea of
feedback - where one port tests another with jumpers between the board
edge connectors. Seems to me the I/O ports would be great for testing
solenoids and lamp drivers when those ports were run at 5VDC B+. Of
course the I/O ports are tested first Outputs to Inputs, perhaps in a
matrix so one can tell which I/O is bad.

And I am sure this would be a lot of work...but isn't it a good
application of Rocket Science?

Thanks,

John :-#)#

[beaver]

Post by John Robertson

Post by beaver
https://edcheung.com/album/album21/asm/asm.htm
I hope others will come up with ideas for improvement and let me know so I can add them, or add these themselves.
Dr Edward Cheung (edcheung.com)
CARGPB26

Hi Ed,
Great news carrying on Leon's work!
If you are looking for suggestions I've always liked the idea of
feedback - where one port tests another with jumpers between the board
edge connectors. Seems to me the I/O ports would be great for testing
solenoids and lamp drivers when those ports were run at 5VDC B+. Of
course the I/O ports are tested first Outputs to Inputs, perhaps in a
matrix so one can tell which I/O is bad.
And I am sure this would be a lot of work...but isn't it a good
application of Rocket Science?
Thanks,
John :-#)#
--
(Please post followups or tech inquiries to the USENET newsgroup)
John's Jukes Ltd.
MOVED to #7 - 3979 Marine Way, Burnaby, BC, Canada V5J 5E3
[phone] (Pinballs, Jukes, Video Games)
www.flippers.com
"Old pinballers never die, they just flip out."

I will give that some thought. Since the game ROMs already test the IOs, what I am trying to focus on is debugging the core CPU/ROM/RAM. Basically what the game ROMs don't do.

[seymour.shabow]

Post by beaver

Post by John Robertson
If you are looking for suggestions I've always liked the idea of
feedback - where one port tests another with jumpers between the
board edge connectors. Seems to me the I/O ports would be great for
testing solenoids and lamp drivers when those ports were run at
5VDC B+. Of course the I/O ports are tested first Outputs to
Inputs, perhaps in a matrix so one can tell which I/O is bad.

Yes, I always wanted this as well. That way you can set up a board for
a burn in mode and have it actually test the inputs instead of just
reading the registers.

Post by beaver
I will give that some thought. Since the game ROMs already test the
IOs, what I am trying to focus on is debugging the core CPU/ROM/RAM.
Basically what the game ROMs don't do.

What do you mean by debugging? The compiled game code or just more
in-depth tests of the ram/rom?

[beaver]

What do you mean by debugging? The compiled game code or just more
in-depth tests of the ram/rom?

More like the latter. Let's say you can't even run the game ROM and its diagnostic. In that case, you put in Leon's ROM (or now my improved version), and try and see what is wrong. It is that kind of debugging that I mean.

Dr Edward Cheung (edcheung.com)
CARGPB26

[beaver]

Another update. It dawned on me that it is possible to use the exact same ROM chip in both System 9 and 11. With what I have learned during this process about their memory maps, the same 27256 ROM can be plugged into either system and work as a board test.

I suppose that is another small improvement over Leon's work. May he RIP.

https://edcheung.com/album/album21/asm/asm.htm

Dr Edward Cheung (edcheung.com)
CARGPB26

[[e-mail]]

Another update. It dawned on me that it is possible to use the exact same ROM chip in both System 9 and 11. With what I have learned during this process about their memory maps, the same 27256 ROM can be plugged into either system and work as a board test.
I suppose that is another small improvement over Leon's work. May he RIP.
https://edcheung.com/album/album21/asm/asm.htm
Dr Edward Cheung (edcheung.com)
CARGPB26

I created test code a while back that steps through the address space of the ROM space and outputs to the header where the two BCD numbers are. I made a seven segment LED board that plugs into the header. The code then outputs 1, blank, 2, blank, 3, blank etc up through the entire address space. This is a rudimentary test of the ROM space accessing to test socket connections and addresses. It has helped me find a few problems. You might want to do something like that.

pinworks

[beaver]

I created test code a while back that steps through the address space of the ROM space and outputs to the header where the two BCD numbers are. I made a seven segment LED board that plugs into the header. The code then outputs 1, blank, 2, blank, 3, blank etc up through the entire address space. This is a rudimentary test of the ROM space accessing to test socket connections and addresses. It has helped me find a few problems. You might want to do something like that.
pinworks

This sounds like a good idea to implement. But I am not clear on the process. It sounds like the point is to check each of the lines on the 16-bit address bus? But you reference "two BCD numbers", which is only a range from 0-99 (BCD goes from 0-9, vs hex which is 0-F). Or perhaps you are saying to toggle each of the address line one by one, and indicate on the header which one is being toggled?

Dr Edward Cheung (edcheung.com)
CARGPB26

[seymour.shabow]

On Wednesday, March 24, 2021 at 9:21:20 AM UTC-4,

Post by ***@bellsouth.net
I created test code a while back that steps through the address
space of the ROM space and outputs to the header where the two BCD
numbers are. I made a seven segment LED board that plugs into the
header. The code then outputs 1, blank, 2, blank, 3, blank etc up
through the entire address space. This is a rudimentary test of the
ROM space accessing to test socket connections and addresses. It
has helped me find a few problems. You might want to do something
like that.
pinworks

This sounds like a good idea to implement. But I am not clear on the
process. It sounds like the point is to check each of the lines on
the 16-bit address bus? But you reference "two BCD numbers", which
is only a range from 0-99 (BCD goes from 0-9, vs hex which is 0-F).
Or perhaps you are saying to toggle each of the address line one by
one, and indicate on the header which one is being toggled?
Dr Edward Cheung (edcheung.com) CARGPB26

He likely means each pair of digits (numbers....)

Sounds like a good idea but use a hex capable display instead and just
output it directly.

[beaver]

Post by seymour.shabow

On Wednesday, March 24, 2021 at 9:21:20 AM UTC-4,

Post by ***@bellsouth.net
I created test code a while back that steps through the address
space of the ROM space and outputs to the header where the two BCD
numbers are. I made a seven segment LED board that plugs into the
header. The code then outputs 1, blank, 2, blank, 3, blank etc up
through the entire address space. This is a rudimentary test of the
ROM space accessing to test socket connections and addresses. It
has helped me find a few problems. You might want to do something
like that.
pinworks

This sounds like a good idea to implement. But I am not clear on the
process. It sounds like the point is to check each of the lines on
the 16-bit address bus? But you reference "two BCD numbers", which
is only a range from 0-99 (BCD goes from 0-9, vs hex which is 0-F).
Or perhaps you are saying to toggle each of the address line one by
one, and indicate on the header which one is being toggled?
Dr Edward Cheung (edcheung.com) CARGPB26

He likely means each pair of digits (numbers....)
Sounds like a good idea but use a hex capable display instead and just
output it directly.

I have thought about it and come up with an interpretation of pinworks' idea.

There are 16 address lines. The new test feature 'blips' each one of these and at the same time outputs which of the 16 are being toggled. So if A15 is toggled, you see a '15' on the custom display. Then it goes to A14, and shows a '14', etc. Is that what is meant by the proposed test?

I am not sure how this would really help as the CPU has to be able to read ROM to run a program. Perhaps it is still useful if the local area between the CPU and PROM are good/undamaged, but we want to extend the check out to the other parts of the board. I will probably implement this but not make use of a custom display. I would just be toggling the address lines. You would use a scope to trigger at the CPU on the address line and then probe elsewhere to see if it matches.

Dr Edward Cheung (edcheung.com)
CARGPB26

[John Robertson]

Post by seymour.shabow

On Wednesday, March 24, 2021 at 9:21:20 AM UTC-4,

Post by ***@bellsouth.net
I created test code a while back that steps through the address
space of the ROM space and outputs to the header where the two BCD
numbers are. I made a seven segment LED board that plugs into the
header. The code then outputs 1, blank, 2, blank, 3, blank etc up
through the entire address space. This is a rudimentary test of the
ROM space accessing to test socket connections and addresses. It
has helped me find a few problems. You might want to do something
like that.
pinworks

This sounds like a good idea to implement.  But I am not clear on the
process.  It sounds like the point is to check each of the lines on
the 16-bit address bus?  But you reference "two BCD numbers", which
is only a range from 0-99 (BCD goes from 0-9, vs hex which is 0-F).
Or perhaps you are saying to toggle each of the address line one by
one, and indicate on the header which one is being toggled?
Dr Edward Cheung (edcheung.com) CARGPB26

He likely means each pair of digits (numbers....)
Sounds like a good idea but use a hex capable display instead and just
output it directly.

One can create a NOP fixture for the CPU - plug that in and each address
toggles twice as fast as the previous one. Then use a frequency counter
or scope to make sure there are no Address lines shorted or open.
Doesn't do anything for the Data bus though it is a simple little test...

I cheat and use my Fluke 9010 though. It catches most logic errors.
However most folks don't have one so I guess this paragraph is just
being annoying. (ducking).

John ;-#)#

[beaver]

Post by John Robertson

Post by seymour.shabow

On Wednesday, March 24, 2021 at 9:21:20 AM UTC-4,

Post by ***@bellsouth.net
I created test code a while back that steps through the address
space of the ROM space and outputs to the header where the two BCD
numbers are. I made a seven segment LED board that plugs into the
header. The code then outputs 1, blank, 2, blank, 3, blank etc up
through the entire address space. This is a rudimentary test of the
ROM space accessing to test socket connections and addresses. It
has helped me find a few problems. You might want to do something
like that.
pinworks

This sounds like a good idea to implement. But I am not clear on the
process. It sounds like the point is to check each of the lines on
the 16-bit address bus? But you reference "two BCD numbers", which
is only a range from 0-99 (BCD goes from 0-9, vs hex which is 0-F).
Or perhaps you are saying to toggle each of the address line one by
one, and indicate on the header which one is being toggled?
Dr Edward Cheung (edcheung.com) CARGPB26

He likely means each pair of digits (numbers....)
Sounds like a good idea but use a hex capable display instead and just
output it directly.

One can create a NOP fixture for the CPU - plug that in and each address
toggles twice as fast as the previous one. Then use a frequency counter
or scope to make sure there are no Address lines shorted or open.
Doesn't do anything for the Data bus though it is a simple little test...
I cheat and use my Fluke 9010 though. It catches most logic errors.
However most folks don't have one so I guess this paragraph is just
being annoying. (ducking).
John ;-#)#
--
(Please post followups or tech inquiries to the USENET newsgroup)
John's Jukes Ltd.
MOVED to #7 - 3979 Marine Way, Burnaby, BC, Canada V5J 5E3
[phone] (Pinballs, Jukes, Video Games)
www.flippers.com
"Old pinballers never die, they just flip out."

Interesting about the 9010. I was not familiar with it (or forgot). To do similar testing, I developed my "PIC68". This is a PIC processor that emulates the 6800 series CPU chips and is controlled by a serial line:
https://www.edcheung.com/album/album09/pinball/pic68/pic68.htm
The PIC68 has a 'mapper' function that outputs address 0x0000 through 0xFFFF on the address bus and sees what any decode logic does (maps out the memory map).

But back to the ROM thread, I just fired up my current test ROM (XFlash) and with it checking all the PIAs, it already toggles all the address lines. So I don't see the need to add a separate section to toggle them. My next work on this will be to allow testing of the audio section of the CPU board with the same ROM. Leon developed a separate ROM for the audio section.

Dr Edward Cheung (edcheung.com)
CARGPB26

[John Robertson]

Post by beaver

Post by John Robertson

Post by seymour.shabow

On Wednesday, March 24, 2021 at 9:21:20 AM UTC-4,

Post by ***@bellsouth.net
I created test code a while back that steps through the address
space of the ROM space and outputs to the header where the two BCD
numbers are. I made a seven segment LED board that plugs into the
header. The code then outputs 1, blank, 2, blank, 3, blank etc up
through the entire address space. This is a rudimentary test of the
ROM space accessing to test socket connections and addresses. It
has helped me find a few problems. You might want to do something
like that.
pinworks

This sounds like a good idea to implement. But I am not clear on the
process. It sounds like the point is to check each of the lines on
the 16-bit address bus? But you reference "two BCD numbers", which
is only a range from 0-99 (BCD goes from 0-9, vs hex which is 0-F).
Or perhaps you are saying to toggle each of the address line one by
one, and indicate on the header which one is being toggled?
Dr Edward Cheung (edcheung.com) CARGPB26

He likely means each pair of digits (numbers....)
Sounds like a good idea but use a hex capable display instead and just
output it directly.

One can create a NOP fixture for the CPU - plug that in and each address
toggles twice as fast as the previous one. Then use a frequency counter
or scope to make sure there are no Address lines shorted or open.
Doesn't do anything for the Data bus though it is a simple little test...
I cheat and use my Fluke 9010 though. It catches most logic errors.
However most folks don't have one so I guess this paragraph is just
being annoying. (ducking).
John ;-#)#
--
(Please post followups or tech inquiries to the USENET newsgroup)
John's Jukes Ltd.
MOVED to #7 - 3979 Marine Way, Burnaby, BC, Canada V5J 5E3
[phone] (Pinballs, Jukes, Video Games)
www.flippers.com
"Old pinballers never die, they just flip out."

https://www.edcheung.com/album/album09/pinball/pic68/pic68.htm
The PIC68 has a 'mapper' function that outputs address 0x0000 through 0xFFFF on the address bus and sees what any decode logic does (maps out the memory map).
But back to the ROM thread, I just fired up my current test ROM (XFlash) and with it checking all the PIAs, it already toggles all the address lines. So I don't see the need to add a separate section to toggle them. My next work on this will be to allow testing of the audio section of the CPU board with the same ROM. Leon developed a separate ROM for the audio section.
Dr Edward Cheung (edcheung.com)
CARGPB26

Your PIC is quite nice.

I'd bought a Aurdino Mega to play with from Paul Swan, but again, my
Fluke does all I need, so the Mega sits on my desk.

Perhaps I'll turn it over to one of my staff to play with...

And it looks like Paul didn't maintain his domain so it only exists on
archive.org:

https://web.archive.org/web/20180419143910/www.paulswan.me/arcade/arduinomegaict.htm

Sigh...

John ;-#)#

[seymour.shabow]

Post by John Robertson
I cheat and use my Fluke 9010 though. It catches most logic errors.
However most folks don't have one so I guess this paragraph is just
being annoying.

Yeah, back when artfromny had TONS of pods and the controller for the
9010, I was like "WTF is that good for? No one except John Robertson
goes on about it".

Now that I know what it does thanks to some youtube videos, you can't
get them, and the guy that was going to remake it on a FPGA board lost
interest and nothing came of it.

[John Robertson]

Post by seymour.shabow

Post by John Robertson
I cheat and use my Fluke 9010 though. It catches most logic errors.
However most folks don't have one so I guess this paragraph is just
being annoying.

Yeah, back when artfromny had TONS of pods and the controller for the
9010, I was like "WTF is that good for?  No one except John Robertson
goes on about it".
Now that I know what it does thanks to some youtube videos, you can't
get them, and the guy that was going to remake it on a FPGA board lost
interest and nothing came of it.

I tried to tell you guys it was a great tool!

This was before youtube though...

John :-#)#

[seymour.shabow]

Post by John Robertson
I tried to tell you guys it was a great tool!
This was before youtube though...

Hmmm I remember more of the "if you don't know how to use it, you
probably don't need it" bent.

I doubt that I wanted to use it for the same reason you would though. I
wanted to use it to snoop around in running software and hack around vs.
fixing boards.

Basically a hardware debugger instead of using pinmame for hacking software.

[[e-mail]]

Post by seymour.shabow

Post by John Robertson
I tried to tell you guys it was a great tool!
This was before youtube though...

Hmmm I remember more of the "if you don't know how to use it, you
probably don't need it" bent.
I doubt that I wanted to use it for the same reason you would though. I
wanted to use it to snoop around in running software and hack around vs.
fixing boards.
Basically a hardware debugger instead of using pinmame for hacking software.

Let me clarify my earlier post. I was in a hurry that day. I got my last Covid shot yesterday and I am not feeling like doing anything active. Williams boards using the 6802 write a BCD number out to the first 4 pins of J5 header and another to the last 4 pins of j5, not counting the key, of course. I use seven of those eight pins. My code puts +5 volts on selected pins so that when a common cathode seven segment led is plugged into the header and the cathode is connected to ground, the seven segment led will display an ever ascending number sequence. The sequence is interspersed with blanks to make it easy to read. The program steps through the entire address space and then goes back to the start. If the program does not perform as expected, you know within a few bytes of where it went wrong.

Sorry for the earlier confusion. I should have looked up the header number on the circuit board instead of referring to the BCD number and confusing everyone.

This routine is of somewhat limited use in that it only finds addressing errors. My favorite tool is an arduino with a ribbon cable and a 40 pin component carrier that plugs into the 6800 or 6502 socket and goes through the ROM, RAM, and PIA chips, turning high one leg at a time. I measure the voltage at the respective leg of the chip. Zero voltage is a broken connection, 2.5 volts is a shorted line. I can test a Williams, Bally, Stern, or Gottlieb board in less than five minutes.

Pinworks