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
On 2021/03/20 8:37 a.m., beaver wrote:
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
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
(604)872-5757 (Pinballs, Jukes, Video Games)
www.flippers.com
"Old pinballers never die, they just flip out."
Yes, I always wanted this as well. That way you can set up a board forIf 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.
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?
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 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.
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.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?
pinworks
On Wednesday, March 24, 2021 at 9:21:20 AM UTC-4,
pinw...@bellsouth.net wrote:
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
beaver wrote: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?
On Wednesday, March 24, 2021 at 9:21:20 AM UTC-4,
pinw...@bellsouth.net wrote:
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) CARGPB26He 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 wrote: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
On Wednesday, March 24, 2021 at 9:21:20 AM UTC-4,
pinw...@bellsouth.net wrote:
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.
On 2021/03/24 8:06 a.m., seymour.shabow wrote: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:
beaver wrote:
On Wednesday, March 24, 2021 at 9:21:20 AM UTC-4,
pinw...@bellsouth.net wrote:
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
(604)872-5757 (Pinballs, Jukes, Video Games)
www.flippers.com
"Old pinballers never die, they just flip out."
On Wednesday, March 24, 2021 at 1:07:29 PM UTC-4, John Robertson wrote:
On 2021/03/24 8:06 a.m., seymour.shabow wrote:
beaver wrote:One can create a NOP fixture for the CPU - plug that in and each address
On Wednesday, March 24, 2021 at 9:21:20 AM UTC-4,
pinw...@bellsouth.net wrote:
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.
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
(604)872-5757 (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
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.
John Robertson wrote:I tried to tell you guys it was a great tool!
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 Robertson wrote: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.
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.
| Sysop: | Gary Ailes |
|---|---|
| Location: | Pittsburgh, PA |
| Users: | 106 |
| Nodes: | 5 (0 / 5) |
| Uptime: | 232:26:15 |
| Calls: | 588 |
| Files: | 2,171 |
| Messages: | 63,915 |