(Topic ID: 328590)

Watchdog Williams Sys7, do anyone have details?

By bontango

1 year ago


Topic Heartbeat

Topic Stats

  • 100 posts
  • 12 Pinsiders participating
  • Latest reply 12 months ago by bontango
  • Topic is favorited by 7 Pinsiders

You

Linked Games

No games have been linked to this topic.

    Topic Gallery

    View topic image gallery

    stack_bug (resized).png
    pasted_image (resized).png
    6800_cpx_flags_notes.jpg
    6800_cpx_flags_modified.jpg
    TTL_Input-Output.png
    sys6_nmi_entry.jpg
    sys6_nmi_ram_check.jpg
    diag loop (resized).png
    08_int (resized).png
    interrupt rom details (resized).png
    interrupt_rom (resized).png
    disp_flash (resized).png
    cmos_test (resized).png
    trace (resized).png
    RTI (resized).png
    IRQ (resized).png

    There are 100 posts in this topic. You are on page 1 of 2.
    #1 1 year ago

    I'm working on a replacement MPU for Williams System3 .. 7 games.
    It will be similar to my 'GottFA' and 'BallyFA' MPUs for Gottlieb and Bally (see www.lisy.dev )

    On the bench I have working displays for System3 & 4 games, but for System6 & 7displays do stop working after a few seconds.
    I assume that is because of the different watchdog implementation for SYS6&7
    According to the schematics SYS7 do generate the IRQ with a 4020 binary counter IC which I emulated in my FPGA
    The resulting signal has a frequency of around 945KHz and an impuls width of 36,5uS
    ( see picture attached, the 'real' signal should be invers but with same waveform)

    Is my IRQ signal correct, anyone have details how exactly the watchdog is implemented?
    thanks

    4020 (resized).png4020 (resized).pngIRQ gen (resized).pngIRQ gen (resized).pngWillFA7_PCB (resized).pngWillFA7_PCB (resized).png
    #2 1 year ago

    As you mention - your interrupt looks inverted from what I measure for the /IRQ signal at TP5. When I was studying timing of the ISR, this is what I measured for the /IRQ (yellow) versus first & last switch strobe:
    Interrupt versus first switch strobe (resized).jpgInterrupt versus first switch strobe (resized).jpg
    Interrupt versus last switch strobe (resized).jpgInterrupt versus last switch strobe (resized).jpg

    When you say your displays go out, is your blanking going low? Is your reset firing?

    #3 1 year ago

    thanks, so my IRQ signal looks almost identical, good
    I didn't implement the Blanking/Reset circuit within the FPGA because I though it is of no use as
    all hardware is emulated in the FPGA anyway, meaning if the FPGA fails, the watchdog circuit around the NE555
    will fail also.
    So, Blanking and Reset are at fix levels at the moment and stable.

    What I see with my logic analysator is that after a few seconds the digit strobes for the displays stop working.
    Sometimes immidiatly, sometimes after a few seconds.

    I did some more tests, and saw that also SYS6 games do running fine, which have the same IRQ gen circuit as SYS7
    So I wonder if IRQ watchdog is really my problem ...

    Compared to sys3..6 this is what I noted have changed:
    - additional PIA at 0x2100 for sound and display comma
    - bigger ram at 0x1000 0x13ff but first 256byte also mapped to 0x0000 to 0x00ff for SYS3..6 compatability
    - bigger roms

    do I miss anything?

    #4 1 year ago
    Quoted from bontango:

    thanks, so my IRQ signal looks almost identical, good
    I didn't implement the Blanking/Reset circuit within the FPGA because I though it is of no use as
    all hardware is emulated in the FPGA anyway, meaning if the FPGA fails, the watchdog circuit around the NE555
    will fail also.
    So, Blanking and Reset are at fix levels at the moment and stable.
    What I see with my logic analysator is that after a few seconds the digit strobes for the displays stop working.
    Sometimes immidiatly, sometimes after a few seconds.
    I did some more tests, and saw that also SYS6 games do running fine, which have the same IRQ gen circuit as SYS7
    So I wonder if IRQ watchdog is really my problem ...
    Compared to sys3..6 this is what I noted have changed:
    - additional PIA at 0x2100 for sound and display comma
    - bigger ram at 0x1000 0x13ff but first 256byte also mapped to 0x0000 to 0x00ff for SYS3..6 compatability
    - bigger roms
    do I miss anything?

    With the 555 emulated, it's hard to imagine why displays would stop working. The processor's interrupt service routine is responsible for strobing the display digits and presenting the BCD data.
    Here are my notes on how the displays are written in the ISR. Each time the interrupt service routine is called (about 960Hz), the following things happen (Sys 3-6):
    PIA1 (Display 0x2800) Port A pins 0-3 are set to the current display digit strobe (1-16).
    PIA1 Port B pins 0-3 are set to the BCD value for displays 3&4, and pins 4-7 are set to the BCD value for displays 1&2.
    If the display digit strobe is 7 or 8, the Ball In Play BDC data is presented on PB 4-7 of Port B.
    If the display digit strobe is 15 or 16, the Credit BDC data is presented on PB 4-7 of Port B.

    Sys 3-6 only need 28 digits, so PB 0-3 isn't used on strobes 7, 8, 15, and 16.

    On Sys 7 the strobes are allocated differently.
    Strobe 1 = left digit of Credits/BIP
    Strobes 2-8 = players 1&3
    Strobe 9 = right digit of Credits/BIP
    Strobes 10-16 = players 2&4

    So, if the "processor" is running and the ISR is being called (and you've tied Blanking high), it's hard to imagine why the displays are going dark...

    As for differences:

    You're not implementing the diagnostic LEDs/7-segment, right?
    Sys 6 has two LEDs controlled by PIA1 (Display) Port A:PA4 & 5, but Sys 7 uses PA 4, 5, 6, and 7 to do a full BCD to 7-segment display for the diagnostic.

    On the driver board in the Switch Columns (drive), R204 to 211 (330 Ohm) were replaced with W9 - W16 (0 ohms).

    #5 1 year ago

    The 4020 is just a 1ms interrupt timer circuit right?

    The watchdog monitors a display PIA ports. That port needs to toggle within the 555 RC time or the blanking goes low shutting down the million 7408s (i guess 74240 hadn't come out yet) doing the blank protection on things like coils and lamps as well as the display blanking at the 4pin plug.

    The power on reset voltage watchdog circuit sucks bad. Again like the 74240, I guess the 3pin reset devices did not come out yet in late 70s. I'd go with a MAX809 equivalent that go for pennies each and delete the mess of transistors they use.

    #6 1 year ago
    Quoted from DickHamill:

    On Sys 7 the strobes are allocated differently.
    Strobe 1 = left digit of Credits/BIP
    Strobes 2-8 = players 1&3
    Strobe 9 = right digit of Credits/BIP
    Strobes 10-16 = players 2&4

    thx, that explains the digits I see after boot on my LCD testdisplay.
    which, after rearangement, shows the expected output from Jungle Lord rom:
    2503 2
    04 00

    Will do some more tests ...

    pasted_image (resized).pngpasted_image (resized).png
    #7 1 year ago

    I think I found the reason for the displays going dark.
    It is not because of the watchdog but because of memory protection.
    I had just implemented a 256Byte CMOS ram, but with SYS6&7 Williams introduced the 'memory protect' circuit.
    With this circuit the upper half of the CMOS is write protected when the coin door is closed.
    Looks like SYS7 roms do a quite strict check when booting by writing and reading the protected area.
    If they find it read only the coin door is supposed to be closed and the game starts, otherwise it comes up with an error.
    SYS6 games are more relaxed here ..
    After implementing the memory protection in the FPGA the displays stay active. I do not see Highscore flashing as with SYS6 but at
    last it is a step forward. Will do a test with real SYS7 pinball at the weekend ...

    #8 1 year ago

    Awesome - I would not have guessed that!
    Thanks for updating.

    #9 1 year ago

    Update: testing with a real pin showed no difference in booting sequence, same behaviour with closed or open coin door
    so only nice theory from my side will investigate further

    #10 1 year ago

    It's definitely not the ~MEM_PROT signal. System 7 code explicitly checks the state when performing the NMI code. I assume the System 6 and System 7 code tests the state if the CMOS checksum does not verify (factory settings restored vs adjustment failure). I haven't seen this code. I only just finished disassembling and looking at the NMI code for both System 6 and System 7.

    #11 1 year ago
    Quoted from DumbAss:

    System 7 code explicitly checks the state when performing the NMI code.

    Can you explain how the state check is done? Is it 'try and error' as I assumed?
    From the schematics I can't see a PIA IO port connected to ~MEM_PROT, so cannot be done directly?!

    #12 1 year ago

    *
    * CHECK FOR MEMORY PROTECT
    *
    ldb #$90 ; assume error 9
    lda $01BB ; check write protect
    inc $01BB
    cmpa $01BB
    beq LFF7B ; write protect, send error code

    System 7.

    IIRC the memory protect blocks the write signal to that chip when the door switch is closed. It's only the upper half of it that's blocked, because you still need audits to increment. It's blocking the settings area. $180-$1FF lower nibble

    I'm not sure if system 6 checks the memory protect when doing diagnostics I didn't see anything on a glance; doesn't mean it's not there, just that it's not called out in the game I looked in.

    #13 1 year ago

    thanks, so it is 'try and error'

    I will now concentrate more on the cmos data.
    My FPGA code do write the cmos content to an eeprom when triggered (e.g. with the 'game on' signal)
    At game start, before the game runs, I read the content from eeprom and do write it to an internal ram.
    Worked so far for my Gottlieb, Bally FPGAs and do work for SYS3..SYS6
    So maybe there is something special with SYS7 in that area or it is a more strict testing
    and my eeprom routine is faulty

    #14 1 year ago

    I am sure you are aware that the 5101 CMOS is a 4-bit SRAM.

    ~MEMORY_PROTECT (I abbreviate to ~MEM_PROT) is an active low signal. It is the coin door switch. The signal is fed into a logic IC used to implement the write protect.

    ~memory_protect.jpg~memory_protect.jpg

    The logic signal processed with the A7 ($80) address bit.

    cmos_5101.jpgcmos_5101.jpg

    • The write signal to pin 20 (R/~W) of the 5101 is only enabled when BOTH R/~W is ~W and the output of IC12 unit C is low.
    • IC12 unit C is low when either ~MEMORY_PROTECT is NOT active or A7=0 ($00-$7F).

    This means that the 5101 is only active for write when:

    • the CPU is writing (R/~W is ~W)

    AND

    • either access is to $0100-$017F OR ~MEMORY_PROTECT is NOT active (coin door is open).

    This implies that writes to:

    • $0100-$017F are always allowed.
    • $0180-$01FF are only allowed when ~MEMORY_PROTECT is NOT active (coin door is open).

    This is the System 7 (from Black Knight) NMI CMOS check code. The System 6 (from Gorgar) NMI CMOS check code is different.

    sys7_cmos_check.jpgsys7_cmos_check.jpg

    #15 1 year ago

    Thanks for providing the disassembled NMI check
    After a few code corrections I'm again one step forward:
    I traced the output for the SYS7 LED digit and when I activate NMI check I can see:
    '9' when the memory protection is active
    '0' when the memory protection is not active
    So it works like it should ...

    I also tried pincoder testroms for SYS7 ( cmos-IC19,ram-IC13, ram-IC16) they all showed a blinking upper LED for OK.

    However after boot, or after the NMI check (where the game should go to attract mode)
    I have still only a few seconds a running display. Sometimes I can see the default highscore '2500000'
    for a few seconds, but most of the time it shows '00' for player1 and for ball & credits.
    Displays still strobing in this state, but no reaction on diag via advance button or any other switch.
    Only the NMI works in this state.

    Looks like a crash for me, so maybe I have an error in my memory mapping for System7?
    See below how I did configured it ( most of it copied from s7.c in pinmame)
    As A15 is not wired (correct?) the upper area ( 8000h-ffffh) is a mirror of the lower area.
    Also I configured 0000-00ff as a mirror for 1000-10ff ( SYS3..6 compatibility)

    Any Idea what I can do for further testing?

    memory map WillFA7:

    IC13+
    IC16 RAM (0000-00ff, 1000-13ff)
    IC19 RAM (0100-01ff)
    IC14 ROM (6000-67ff)
    IC17 ROM (7000-7fff)
    IC26 ROM (5800-5fff)
    IC20 ROM (6800-6fff)

    { 0x2100, 0x2103, pia_w(S7_PIA0)},
    { 0x2200, 0x2203, pia_w(S7_PIA1)},
    { 0x2400, 0x2403, pia_w(S7_PIA2)},
    { 0x2800, 0x2803, pia_w(S7_PIA3)},
    { 0x3000, 0x3003, pia_w(S7_PIA4)},

    #16 1 year ago

    Ram should go from $0000-$00FF

    #17 1 year ago
    Quoted from slochar:

    Ram should go from $0000-$00FF

    thanks, in fact I have implemented it up to 00ff, was a typo copied from the pinmame source
    ( I corrected it in my last post)

    #18 1 year ago
    Quoted from bontango:

    Looks like a crash for me, so maybe I have an error in my memory mapping for System7?

    This is what I have for definitions. It's not official nor definitive. It's what I worked through based on code and schematics.

    // These are addresses in the address space. Address space decoding is done in
    // hardware on the CPU board.

    static unsigned short const SRAM_BASE = 0x0000;
    static unsigned short const SRAM_LIMIT = 0x0100;
    static unsigned short const CMOS_BASE = 0x0100;
    static unsigned short const CMOS_SCRATCH = 0x01BB;
    static unsigned short const CMOS_LIMIT = 0x0200;
    static unsigned short const XRAM_BASE = 0x1000;
    static unsigned short const XRAM_LIMIT = 0x1400;
    static unsigned short const PIA_BASE = 0x2000;
    static unsigned short const PIA_SOUND = 0x2100;
    static unsigned short const PIA_SOLENOIDS = 0x2200;
    static unsigned short const PIA_LAMPS = 0x2400;
    static unsigned short const PIA_DISPLAY = 0x2800;
    static unsigned short const PIA_SWITCHES = 0x3000;
    static unsigned short const ROM6_BASE = 0x6000;
    static unsigned short const ROM6_LIMIT = 0x7FFF;
    static unsigned short const ROM7_BASE = 0xC000;
    static unsigned short const ROM7_EXTENDED = 0xE04C;
    static unsigned short const ROM7_LIMIT = 0x0000; // overflow 0x00010000
    static unsigned short const ROM_IC_SIZE = 0x0800;

    Quoted from bontango:

    As A15 is not wired (correct?) the upper area ( 8000h-ffffh) is a mirror of the lower area.

    System 9 CPU boards do not have A15 connected to anything. As does System 6 and System 7. I have never seen an OEM System 6 or System 7 CPU board in person. I assume the schematic is correct but I have not verified on an actual board.

    This mean that the hardware doesn't respond to it and the address map is the same for $0000-$7FFF as it is for $8000-$FFFF. The CPU takes the reset entry from the reset vector. This is $FFFE/$FFFF. In System 6, the address is $7000. In System 7, the address is $E800. The could just as easily be $F000 or $6800. It's just that Williams declared the origin (ORG) as $7000 in System 6 and $E800 in System 7.

    When working through the schematics, I did notice that the addresses for the corresponding ICs are different. This is because the ROM mapping of IC to address was changed. The flipper ROM in System 6 is $1000 (2x ROMs) in size whereas in System 7 it is $1800 (3x ROMs) in size. To reduce requirements from 3x ROMs to 2x ROMs, one of the ROMs was increased from a 2716 ($0800) to 2732 ($1000).

    • System 6
      • IC14 16kb $6000 $67FF
      • IC20 16kb $7000 $77FF
      • IC17 16kb $7800 $7FFF
      • IC21 4kb $6000 $61FF
      • IC22 4kb $6200 $63FF
      • IC26 4kb $6400 $65FF
    • System 7
      • IC26 16kb $5800 $5FFF
      • IC14 16kb $6000 $67FF
      • IC20 16kb $6800 $6FFF
      • IC17 32kb $7000 $7FFF
      • IC21 4kb $6000 $61FF
      • IC22 4kb $6200 $63FF

    Remember: none of this is official. It's only what I figured out from staring at the schematics for hours on end.

    If you are emulating or responding to the ICs as each IC then you need to know where they are mapped. If you are just looking at the address space in some form of contiguous manner then it doesn't matter because it's just address space.

    #19 1 year ago

    I used my logic analyzer to track CPU addresses
    At boot time, it looks fine, system reads the reset vector and starts the programm at E800h
    When I trace a few seconds later, the CPU just increment the addresses
    I try to find a trigger for my logicanalyzer to see where the crash happens, but no luck so far
    Any idea?

    boot_OK (resized).pngboot_OK (resized).pngcrashed (resized).pngcrashed (resized).png
    #20 1 year ago

    after two days of debugging I think its something around Williams is doing the RAM adressing
    which is incompatible with the usual way a FPGA is doing RAM emulation.
    I can see access to the ram area and then the programm is jumping to 'somewhere' ...

    I have found a 15 years old thread on rec.games.pinball which talks about "Williams "sloppy" RAM addressing"
    https://rec.games.pinball.narkive.com/48WgXWY2/fyi-rottendog-williams-system-3-7-como-mpu-driver-update

    Anyone have more details on that?
    thanks

    #21 1 year ago

    There is a function in system 7 that does inline assembly that copies code from rom to ram, executes it out of ram, then jumps back to rom. I don't know if that would affect what you're doing though.

    Does it always stop on the same ram address? What game rom are you using to test?

    #22 1 year ago

    Could be the reason, need to investigate.

    Difficult to find the 'point' where it gets out of line.
    I did some traces triggering on a signal which I set high if the programm jumps to a memory region which
    I did not decode in my program. But the point is more or less random ...

    Do you know if the region where to ram copy and execution is done at a fix address?
    If so, I can set a trigger to that address.

    The failing routine is somewhere at beginning of attract mode when it starts to show highscores.
    So happens directly after boot and also after I set NMI and the routine goes back to attract mode.
    On my testdisplay I can see sometimes highscores ( Jungle Lord with 2,000,000) for a short moment but then display strobing goes dead.

    I tested with different SYS7 roms, Black knight, Jungle Lord, with same results

    #23 1 year ago

    $1130 in black knight. Ends at max $113F depending on the code being executed, and always ends with jmp $f3CD (7e f3 cd)
    The game uses this functionality all the time, and definitely in attract mode.

    #24 1 year ago

    did some more tracing ... added screenshots from my Logicport
    - first line is address bus
    - second line data bus
    - ram_S7_cs is high when SYS7 ram is selected
    - ram_wren is high when system writes to S7 ram
    - is_F3CD is low when address is $F3CD
    - i_addr is low when there is an address which is not decoded in my program

    picture 2:
    Triggered on $F3CD and looks OK for me .. jmp is coming from ram $1136 $1137 $1138
    can you confirm?
    However: I only see this address ONE Time after boot

    picture1:
    Triggered on 'i_addr' and can see program is adressing $0200
    I see counting from $0 to $0200 ...
    Picture shows point in time where I think it starts going 'out of line' by counting 0,1,2,3,4,
    Can you identify whats happening, do you see anything familiar from the address range?

    thanks for your help

    i_addr (resized).pngi_addr (resized).pngtrigger_F3CD (resized).pngtrigger_F3CD (resized).png
    #25 1 year ago

    So you see addresses $0000-$0200 activating in a loop? Or was it $01FF-$0000 (reverse order)? When the cmos gets cleared it does start at $1ff and go down to $0000. If you don't have a successful boot that saves the cmos for next time, it will do this on every bootup and go into audit mode.

    #26 1 year ago

    I had the 'clear' before, but now I use the 'init_cmos' data from pincoder, and can see that CPU is reading it correctly, no clear anymore.

    Its starting at $0000 and then goes towards $0200 and above, looks like the CPU is walking to all addresses
    At picture 1, timemark +6uS you see the start
    Wonder why this happens ...looks like it is executing commands from ram at $1215 ... $121B

    1 week later
    #27 1 year ago

    SYS4 (Flash) and SYS6 ( Firepower & Trident ) tests running fine, still problems with SYS7.
    I did went back to 'basic' testing with pincoder roms today and found out that I may have interpreted the results
    from pincoder wrong; because I was confused by the way LEDs are drawn in schematics.

    Pincoder and Williams diagnostic results are based on 'upper' and 'lower' LED.
    As I do not have any original boards could please someone confirm that the upper LED on the board is LED1 in schematics
    and the lower LED on the board is LED2 in schematics?
    Meaning upper LED on board is connected to "PIA I PA5" and lower LED on board connected to"PIA I PA4"?
    thanks

    diag LEDs Williams (resized).pngdiag LEDs Williams (resized).png
    #28 1 year ago

    Hi, Just saw this thread and now catching up.. Two things I can offer that may help:

    1) The actual System 6 (and likely 3-7) Williams code has A15 flailing around (seemingly at random) in all of the instructions that refer to address space. The MPU board doesn't actually use A15 in the circuitry and so all of the Williams code runs just fine. I suspect they designed it for a 15 bit address space, and then used the 16th bit as some sort of debug/trigger bit, and they just never cleaned it up when they released the code.

    Mirroring both "halves" should solve that problem, but I'm not an FPGA guy so I can't verify how they might behave. Something to consider.

    2) While I'm not certain where and when the williams code decides whether the CMOS data is valid, I do know that clearing the whole thing out (setting all nibbles to 0xF) will certainly trigger the williams code to write default values into the CMOS in the fashion it is happy with. To accomplish this, use the pincoder "clear_cmos" test ROM (with coin door open / write protect off scheme in place) before running the Williams code.

    If the Williams code can't tell that the CMOS data is invalid it will go into attract mode anyway and you will sometimes see strange things like the default high score being wonky.

    Further (and you already know this) if you want to test your FPGA board while having the Williams code pass its own CMOS data test and go directly into attract mode, run the "init_cmos" ROM first.

    So, if after running the "03-cmos" test (or if you are seeing a wonky behaviors like default high score etc) you should most definitely run the clear_cmos or init_cmos ROMs BEFORE you run any of your own tests with the Williams code.

    Finally, you had PM'd me asking how to find where (address wise) the pincoder RAM tests were identifying a failure on sys7. The code for 04-ram is the same for sys3-7 but in sys7 the data mask is different. This is because:

    * in sys3-6a: each ram chip is tested for 8 bits.
    * in sys7: the two RAM chips are 4 bits wide, and are each wired to respond to identical addresses, resulting in 8 bits of data for one address.

    Could the problem be in your backward compatibilty handling of RAM data bits?

    On a Williams sys7 board, setting the jumpers to correctly behave as a system3-6 board results in the software itself not seeing any difference in data mask. The two chips appear as one.

    If you want to find where the ram test is failing, set your logic analyzer to trigger on the bottom LED anode and run the pincoder 04-ram test. When the data is captured, go backwards from the trigger point and you will see "PIA1 port A" on the address bus (to light the bottom LED) and the first valid chip address before that will be the location in the RAM chip that failed the test.

    Hope that helps

    Craig

    PS: Pincoder ROMs run with a clean A15 address pin

    #29 1 year ago

    Oh, almost forgot:

    sys346 and sys6a:
    .define DEF_TOP_LED_BIT /$$20/
    .define DEF_BOT_LED_BIT /$$10/

    sys7:
    .define DEF_TOP_LED_BIT /$$10/
    .define DEF_BOT_LED_BIT /$$20/

    When writing to LEDs on PIA1_A

    This may have been tripping you up all along. I switched them in the pincoder stuff so that the Top LED was always physically the upper LED and it made sense to keep documentation as similar as possible. I hope it has not caused you too much grief.

    Craig

    #30 1 year ago
    Quoted from pincoder:

    sys346 and sys6a:
    .define DEF_TOP_LED_BIT /$$20/
    .define DEF_BOT_LED_BIT /$$10/

    sys7:
    .define DEF_TOP_LED_BIT /$$10/
    .define DEF_BOT_LED_BIT /$$20/

    When writing to LEDs on PIA1_A

    Ahhh, thats the reason why I couldn't see any error in my trace of SYS7 ramtest, because the test didn't detect any error.
    I just looked to the wrong LED on my board
    So now I can see that both SYS346 & SYS7 ram&cmos tests reporting OK.

    Based on that I will more concentrate on the initial cmos data and your other hints, let you know about my findings.
    Many thanks for your help, thats a big step forward ...

    #31 1 year ago

    system 7 takes the nibbles at $017D-$0180 and combines them into A/B, then adds them up. Ignoring carries it has to sum to #$57 or it resets the cmos with defaults.
    So the individual nibbles are: xB,x2 ($B2 in A), xA,x5 ($A5 in B) (x is 'don't care' - the upper nibble gets returned as $F usually.

    #32 1 year ago
    Quoted from slochar:

    system 7 takes the nibbles at $017D-$0180

    My traces confirm that the first cmos addresses read are $017D-$0180, in case of a 'init' cmos ($0F)
    the program sets the Black Knight initial values listet by pincoder, so that a boot afterwards accept the cmos data and do not write the defaults.
    So far so good ... but (with Black Knight L4 rom) the programm crashes after a few seconds in both cases!
    This happens with the cmos init data ($0F) (test1) as well as with the correct cmos data settings (Test2)

    I was able to identify and reproduce the last instructions which do looking good (for me) before the programm crashes.
    Maybe that does ring a bell, pls. have a look below ...
    Esspecially for test case 1, I think the program does not do much beside showing the rom code and level on the displays?

    ------------------------------
    Test1:
    Last 'good' instruction is RTI ($3B) 'Return from interrupt' at address $F10D
    At this point in time the stack pointer is pointing to $11A9 ( not 100% reproducable, but it is near this range all the time)
    Program is pulling 7 bytes now from the stack memory, however as byte 6 is $00 and byte 7 is $AA (stored program counter) the program jumps to $00AB and crashes
    Display is showing
    2500 4
    0400
    for a short moment, then with the programm crashing, the display go black
    ------------------------------
    Test2:
    Last 'good' instruction again is RTI ($3B) 'Return from interrupt' at address $F10D
    At this point in time the stack pointer is pointing to $11CD ( not 100% reproducable, but it is near this range all the time)
    Program is pulling 7 bytes now from the stack memory, however as byte 6 & 7 (stored program counter) are $00, the program jumps to $0001 and crashes
    Display is start showing default high cores for a short moment, then with the programm crashing, the display go black

    #33 1 year ago

    I'm glad that's all it was for the ram test issue.

    Just thinking more again on the A15 stuff. Mirroring ROM space is an easy fix but if they've also got it happening for RAM/cmos/pia addresses (which is quite likely) then there's going to be a problem.

    Please bear in mind my experience of examining williams code is limited to system 6, so I will speak as such. As far as the sys3-4 and 6a-7 evolution goes, I'd bet the A15 issue is also present in at least 3,4, and 6a. sys7 may be different as there was much bigger changes to the board itself.

    So, please take the following system 6 information with a grain of salt when thinking of applying it to the remaining sys3-7 set of boards and code.

    If you implement a true 16 bit address space, you'd have to implement two PIA chips for each physical PIA and copy their registers back and forth. With RAM and cmos, same thing. This is probably a lot of work in an FPGA.

    If you haven't already, consider designing your board to ignore A15 and run with a 15 bit address bus. This seems to be the easiest to implement and follows the logic of true hardware emulation. Seems odd to carry things like this forward into next generation hardware, but true is true and it will ensure the williams code runs fine.

    A long while back I developed an expansion board for my gorgar. I was able to add 8K of RAM and 8K of ROM to the system 6 board by utilizing A15 and cleaning up the williams code, setting A15 to zero in all of their stuff, and setting it to 1 in the additional code I created to go with the williams code. This allowed me 15 bits of my own addressable space while still allowing the Williams to have it's 15 bits.

    At certain points in the williams code I inserted jsr and jmp instructions to their code and so I was able to create software mods to the game. Since there are unused driver board outputs I was also able to make hardware mods, that got triggered by the software mods.

    The catch here is that for this to work I had to modify the system 6 MPU board.. cut a few traces and added a 74lsxx logic chip to gain proper (no conflict) access to the address bus.

    What it comes down to for both of us, and really everyone else, is that the licensing for Williams code does not allow public modification of such, and so we all have to work around the mistakes Williams made on those early games.

    I can say however, that cleaning up A15 in the system 6 code works perfectly, so if your design simply ignores A15 you should have no problems using their original code - at least for system 6.

    #34 1 year ago
    Quoted from bontango:

    My traces confirm that the first cmos addresses read are $017D-$0180, in case of a 'init' cmos ($0F)
    the program sets the Black Knight initial values listet by pincoder, so that a boot afterwards accept the cmos data and do not write the defaults.
    So far so good ... but (with Black Knight L4 rom) the programm crashes after a few seconds in both cases!
    This happens with the cmos init data ($0F) (test1) as well as with the correct cmos data settings (Test2)
    I was able to identify and reproduce the last instructions which do looking good (for me) before the programm crashes.
    Maybe that does ring a bell, pls. have a look below ...
    Esspecially for test case 1, I think the program does not do much beside showing the rom code and level on the displays?
    ------------------------------
    Test1:
    Last 'good' instruction is RTI ($3B) 'Return from interrupt' at address $F10D
    At this point in time the stack pointer is pointing to $11A9 ( not 100% reproducable, but it is near this range all the time)
    Program is pulling 7 bytes now from the stack memory, however as byte 6 is $00 and byte 7 is $AA (stored program counter) the program jumps to $00AB and crashes
    Display is showing
    2500 4
    0400
    for a short moment, then with the programm crashing, the display go black
    ------------------------------
    Test2:
    Last 'good' instruction again is RTI ($3B) 'Return from interrupt' at address $F10D
    At this point in time the stack pointer is pointing to $11CD ( not 100% reproducable, but it is near this range all the time)
    Program is pulling 7 bytes now from the stack memory, however as byte 6 & 7 (stored program counter) are $00, the program jumps to $0001 and crashes
    Display is start showing default high cores for a short moment, then with the programm crashing, the display go black

    Debugging at this level with a logic analyzer and without the ability to examine actual contents of RAM and CMOS at the time of crash can be extremely difficult. It would be so much nicer to be able to interrupt the CPU and step through things one at a time.

    Are you able to implement some sort of debugger in your FPGA? Perhaps a way to insert break points and examine the state of things..

    #35 1 year ago

    According to pinmame source only rom address space is mirrored in SYS7 and Sys7 do run in pinmame ...
    However my address decoding ignores A15 all over the place, so that should be OK.
    I triggered on 'invalid addresses' within my code, only when the programm crashes invalid addresses shows up.
    SYS3 up to SYS6 are running fine with my hardware emulation, so must be 'something' special with Sys7.

    And you are right, debugging with logic analyzer is extremly limited, I will think about FPGA debugging but never did that before.

    Next plan is to have a more detailed look on things happening in pinmame, my other 'product' LISY do support
    system7 together with APC https://lisy.dev/apc.html debugging within a linux environment I did before..
    maybe I see some differences ...

    thanks for your support

    #36 1 year ago
    Quoted from pincoder:

    It would be so much nicer to be able to interrupt the CPU and step through things one at a time.

    What I would give for a single step exception (SSE) ala Intel processors.

    System emulators (such as pinmame) are great for this purpose. However, they assume the hardware circuitry is correct. They don't emulate problematic hardware, so emulators don't work well for debugging hardware.

    #37 1 year ago
    Quoted from DumbAss:

    What I would give for a single step exception (SSE) ala Intel processors.
    System emulators (such as pinmame) are great for this purpose. However, they assume the hardware circuitry is correct. They don't emulate problematic hardware, so emulators don't work well for debugging hardware.

    Yes this is an interesting twist in the debugging world: assume the software is okay and troubleshoot the hardware instead!

    #38 1 year ago
    Quoted from pincoder:

    Yes this is an interesting twist in the debugging world: assume the software is okay and troubleshoot the hardware instead!

    Or, in my case, troubleshoot the emulated hardware

    #39 1 year ago
    Quoted from bontango:

    Or, in my case, troubleshoot the emulated hardware

    Yes! You've got a really cool project on the go!

    #40 1 year ago
    Quoted from bontango:

    ------------------------------
    Test1:
    Last 'good' instruction is RTI ($3B) 'Return from interrupt' at address $F10D
    At this point in time the stack pointer is pointing to $11A9 ( not 100% reproducable, but it is near this range all the time)
    Program is pulling 7 bytes now from the stack memory, however as byte 6 is $00 and byte 7 is $AA (stored program counter) the program jumps to $00AB and crashes
    Display is showing
    2500 4
    0400
    for a short moment, then with the programm crashing, the display go black
    ------------------------------
    Test2:
    Last 'good' instruction again is RTI ($3B) 'Return from interrupt' at address $F10D
    At this point in time the stack pointer is pointing to $11CD ( not 100% reproducable, but it is near this range all the time)
    Program is pulling 7 bytes now from the stack memory, however as byte 6 & 7 (stored program counter) are $00, the program jumps to $0001 and crashes
    Display is start showing default high cores for a short moment, then with the programm crashing, the display go black

    So it's crashing in both cases coming out of the periodic interrupt. This is unfortunate as there's a lot of core functionality in that interrupt so neither of those crashes really points a finger at anything. Does the way the FPGA runs the 6800/6821 cores always start at the same strict timing? (For instance, in pinmame a trace like this would always be reproduceable, as it 'starts' the emulation the same way everytime with the same values. This is why input playback files 'work' for recording gameplay)

    That would help isolate what's going on.

    The IRQ goes to $E0BF which is just a jump to the 'real' irq at $EFF7. If you can isolate the number of times this gets called that might be a clue as to when it's crashing. Not all of the IRQ is used everytime through the routine, there are some system timers that wouldn't make sense to increment each time through (they would ramp up too quickly). This timer is at $0095.... it increments whenever display strobe 0 is active.

    #41 1 year ago

    Tried to count number of IRQs until crash, but failed ...
    Then I searched for $EFF7 and was able to find last IRQ in my trace
    When IRQ (active high in my case) comes in, I see that correct data is stored on Stack, Stackpointer is $13F1 afterwards
    Looking to RTI when the crash happens, Stackpointer however is $1203 ???
    ( see pictures below)
    So there must be some illegal stack pointer manipulation in between?

    Within the trace I can see Display($2800..3) & Switch ($3000..3) PIA activity but NO access to ram at $0095

    Does that help?

    IRQ (resized).pngIRQ (resized).pngRTI (resized).pngRTI (resized).pngtrace (resized).pngtrace (resized).png
    #42 1 year ago

    I just want to say I enjoy following these discussions even though 50% of what is being discussed is lost on me. Kudos to those whom enjoy this aspect of pinball!

    #43 1 year ago

    that's very odd, the interrupt does not do anything on the stack (other than the registers & return address being saved as part of the interrupt request, and it should restore them all).

    The 0095 not being accessed just means that part of the interrupt didn't run because the display strobe wasn't 0.

    Since the 680x core runs correctly on system 3-6, is it possible there's a bug in the core when the stack is set off zero page? 3-6 always uses zero page for the stack, as it's the only full byte ram available. System 7 uses higher ram (and at setup, rom) as the stack pointer. At bootup the PIA addresses are read as the stack to set them up. (interrupts are blocked, here)

    Whenever a process sleeps, the stack is reset to the top $13f7, looks like the absolute bottom would be $13A2 based on the # of data silos black knight sets up (29). I tested bk_l4 in pinmame in attract mode and audit mode and it never went below $13db.

    #44 1 year ago
    Quoted from slochar:

    that's very odd, the interrupt does not do anything on the stack (other than the registers & return address being saved as part of the interrupt request, and it should restore them all).

    ... unless the interrupt routine itself causes the core to wrongly manipulate the stack.. ? What parts of the core is the interrupt code accessing?

    #45 1 year ago

    Also curious, does the sys7 version of the 08-interrupts test function properly? How about the sys346 and sys6a versions under the appropriate emulations?

    #46 1 year ago
    Quoted from gdonovan:

    I just want to say I enjoy following these discussions even though 50% of what is being discussed is lost on me. Kudos to those whom enjoy this aspect of pinball!

    It's great that you are following along

    #47 1 year ago
    Quoted from slochar:

    Since the 680x core runs correctly on system 3-6, is it possible there's a bug in the core when the stack is set off zero page?

    Yes possible, had a look to the code and will 'export' the SP register to be able to include that in the trace and track when it changes.
    Need some time as I'm running out with IOs on my Logicport, so have to rearrange my test environment
    I uploaded the 6800 core ( cpu68.vhd ) along with my code to github, if you want to have a look
    https://github.com/bontango/WillFA7

    Quoted from pincoder:

    Also curious, does the sys7 version of the 08-interrupts test function properly? How about the sys346 and sys6a versions under the appropriate emulations?

    Did not test your interrupt roms yet, but will do ASAP

    In the meantime I had some feedback from my SYS4 and SYS6 testers; two bugs with SYS4 & SYS6:
    1 - when pressing 'Diag switch' (NMI) the self test fails. Upper LED is On and system 'hangs' ( According to docs that is caused by a faulty ram?)
    Same behaviour with pinmame btw. so looks like there are also still some bugs in pinmame Williams code
    2 - System does not take care of changed settings. I changed 'max credits' to '10' and can verify changed setting at No.18 still at '10'
    in the setting menu after a boot, but I'm still able to add credits up to the default maximum ????

    So will put the focus on the new SYS4/6 bugs for the moment, with some hope that solving these bugs will also solve the SYS7 bugs

    #48 1 year ago
    Quoted from pincoder:

    It's great that you are following along

    Back in the 90s I did some limited reverse engineering of Chrysler 85 to 91 ECMs. Just enough to tune them though others went further by adding various features. Real stone age stuff doing work with hex editors and calculating tables with Lotus 1 2 3.

    The actual tuning was were I shined, I crammed the software in my head because it was a necessary evil to get where I wanted to go.

    #49 1 year ago

    pincoder I'm playing around with the cmos data on SYS6(Gorgar) to find the reason why max_credits are not recognized
    My traces showing that while in settings Gorgar does save the max_credits at $1CF and $1D0, you stated in your
    edit_cmos explanation that it is on decimal 395,396 ( $18B, $19B )
    Is this another bug on my side, or is it an error in your table?

    #50 1 year ago

    Something's wonky there, $18B,$18C (upper/lower nibble of max credits setting #18) is where I show it saving (which matches 395-396)

    Quoted from bontango:

    I uploaded the 6800 core ( cpu68.vhd ) along with my code to github, if you want to have a look

    I'll look at that but that's out of my skill set

    There are 100 posts in this topic. You are on page 1 of 2.

    Reply

    Wanna join the discussion? Please sign in to reply to this topic.

    Hey there! Welcome to Pinside!

    Donate to Pinside

    Great to see you're enjoying Pinside! Did you know Pinside is able to run without any 3rd-party banners or ads, thanks to the support from our visitors? Please consider a donation to Pinside and get anext to your username to show for it! Or better yet, subscribe to Pinside+!


    This page was printed from https://pinside.com/pinball/forum/topic/watchdog-williams-sys7-do-anyone-have-details?hl=pincoder and we tried optimising it for printing. Some page elements may have been deliberately hidden.

    Scan the QR code on the left to jump to the URL this document was printed from.