(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 2 of 2.
    #51 1 year ago

    OK, so there is still a bug with SYS4/6. Looks like the setting routine do save&read at wrong places which would explain why I see
    the changed settings in the settings menu but the system do not recognize them because it looks at the right places ...

    Quoted from slochar:

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

    I recommend to try it out, FPGAs are great devices and you have all the skills needed.
    The programming language for FPGAs (VHDL) 'just' describes hardware.
    cpu68.vhd and the PIA emulation code is free software which, I have to admit, is also out of my skill set
    BUT I bet by reading my 'WillFA7.vhd' you will understand 80% of the code.
    You said you are looking for a single step exception for 680x processors?
    Doing 'a bit' of a change to cpu68.vhd adding SSE and building 5V drivers around an FPGA would give you that ...

    #52 1 year ago
    Quoted from gdonovan:

    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.

    Lotus 1 2 3?? ACK! I was lucky enough to be able to steer clear of that one

    #53 1 year ago
    Quoted from pincoder:

    Lotus 1 2 3?? ACK! I was lucky enough to be able to steer clear of that one

    I think I could loan you a copy! Lol

    #54 1 year ago

    I agree, FPGAs are truly great to work with, we quite often use the Xilinx Virtex series. One thing to watch out for -- Some of the CPU emulators out there are functional emulators but not pure timing emulators. They will run all the code but not all of the instructions will have the same number of clock cycles as the original. Sometimes the old designs used tight loops for delays. Using instructions with fewer clock cycles will cause loops to run too fast or too slow. If I remember correctly, there is a table out there that compares CPU68 clock cycles to the original 6800 clock cycles and you might need to tweak the code in a few places. But I think it was a bigger issue with 6502 emulation.

    Wayyy back in school days, we designed our own CPU using CPU emulation. Added instructions to the CPU one by one, in the end it was quite abit of code.

    #55 1 year ago
    Quoted from G-P-E:

    Some of the CPU emulators out there are functional emulators but not pure timing emulators. They will run all the code but not all of the instructions will have the same number of clock cycles as the original.

    Raw interpreters (emulators) or JIT compilers fall into this category. They just execute the intent of the original code to the level of correctness that they implement ignoring actual clock cycles. Often timing and synchronization in these systems uses a different method (such as VBLANK = VBI = vertical blanking interrupt).

    Quoted from G-P-E:

    Sometimes the old designs used tight loops for delays. Using instructions with fewer clock cycles will cause loops to run too fast or too slow.

    I once wrote a 6502 emulator years ago and the biggest issue was with sound effects. These machines had simple speakers that you would hit a MMIO location to toggle the speaker state. The delays between toggling would cause different wave forms and therefore different sound effects. If you got the timing wrong then the sound effect would be wrong. This kind of issue would also apply when it came to writing data to the peripheral (floppy disk drive - remember those?) where the write routine used "stall" instructions to meet a specific cycle count for each chunk of data being output.

    Thanks for taking me down memory lane for fun stuff from decades ago.

    #56 1 year ago
    Quoted from bontango:

    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?

    The pincoder documentation is correct. The decimal 153 ($99) and 154 ($1A) are an INDEX into the CMOS, which starts at decimal 256 ($100) so maximum credits is stored at (256+153=395) decimal 395 and 396 ($18B and $18C).

    Created a test rom for you in this beta version:

    https://pincoder.ca/ccn/roms/pincoder_roms_2023.02.01.1722_beta.zip

    There is a "show_maxcred" image that is identical to "edit_cmos" except that it starts at the maximum credits address (decimal 395) so you don't have to keep pressing the HS RESET button to get there. Note that on sys7 (possibly only black knight) the max credits address is decimal 427.

    I did an actual test on Gorgar and 395 and 396 are the correct addresses.

    #57 1 year ago

    I'm happy to bring up good old memory to all of you

    Quoted from G-P-E:

    If I remember correctly, there is a table out there that compares CPU68 clock cycles to the original 6800 clock cycles and you might need to tweak the code in a few places.

    I found a cpu68 version here https://github.com/jboone/robotron-fpga-verilog/blob/master/rtl/cpu68.vhd
    which states: "6800: Extend some instructions to match cycle count in data sheet. "
    Tried it and at least SYS7 do behave 'different'
    Maybe I need to dig in the code, to extend 'some instructions' to 'all instructions'

    Quoted from pincoder:

    Created a test rom for you in this beta version:

    Thx, see attached picture what I see on my testdisplay when using this rom.
    At least the value '002' looks OK, but the other parts?

    Did some additional testing verified each setting at Gorgar with logicport traces triggering on cmos write,
    it turned out that EACH setting is stored with on offset of 69 ($45 ) in cmos area.
    Hoping that this is consistent to all SYS4..6 I will build a workaround version and copy the values
    to the correct location whenever a write to the upper cmos area occurs.

    Hoever, would love to know from where this offset comes ...

    cmos_test (resized).pngcmos_test (resized).png
    #58 1 year ago

    The workaround for SYS4&6 menu settings is working

    Small correction on the offset, it is 68 ($44) not 69! Binary data of offset is "0100 0100"

    What I do:
    I have a flash memory which stores Cmos data, data is read at boot from Flash and write to cmos with triggers ( e.g. advance button)
    After Williams has wrote the defaults to cmos I copy cmos data $81..$BB to $C5..$FF with this the setting menu show the default values for High score, ...
    Each time cmos data is changed and written to flash, I copy data from $C5..$FF to $81..$BB so that the system could find it after the next boot.
    Tested with Flash, Gorgar, Firepower roms. Hope that it work with other games too.

    Any idea why my FPGA do this offset, and only in the settings menu?
    Would like to get rid of this (ugly) workaround.

    #59 1 year ago
    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?

    pincoder I tried your SYS7 08-interrupt test, Display shows
    253 031
    693 005
    for
    player1 player2
    player2 player4

    I do not have DIP Switch1 on my testboard, pressing SW1 (NMI) changes numbers at player1 & player3 to 'random' numbers in range 2xx 6xx
    I don't think thats the expected behaviour ...

    When NMI is executed I can see in my trace loading of int vector $FFFC & $FFFD jumping to $7E59 executing a 'RTI' so continue at the programm where the NMI occured.

    Do you have any specific addresses which I should check?

    #60 1 year ago

    EDIT: had the wrong rom selected, sorry
    Display is showing

    233X 033 X
    633X 003 X
    for
    player1 player2
    player2 player4
    with 'X' counting from 0 .. 9 each second

    X counting stops when I push 'NMI', another push to NMI continue counting
    Beside the additonal digits I think thats OK?

    #61 1 year ago
    Quoted from bontango:

    EDIT: had the wrong rom selected, sorry
    Display is showing
    233X 033 X
    633X 003 X
    for
    player1 player2
    player2 player4
    with 'X' counting from 0 .. 9 each second
    X counting stops when I push 'NMI', another push to NMI continue counting
    Beside the additonal digits I think thats OK?

    For 08-interrupts test all four player displays should be showing the same value (XHHMMSS), incrementing every second, where X is blank on system 7. Credit and match should both show Number of Days: initially"00". The NMI switch correctly starts and stops the count as you are seeing.

    Remember that sys7 displays have different strobe arrangements for the digits, though what you are seeing there doesn't look like a strobe mismatch. A mismatch would show the correct values for the digits, but they would basically be in scrambled locations on the displays, so seeing the 2's and 3's and 6's tells me your board is quite possibly displaying the values for the wrong address locations, or the correct locations but they have the wrong values.. Are you able to test with genuine Williams display boards? I know some of the aftermarket bench LCD display equivalents do not always function perfectly because they take shortcuts in their design. If you cannot find williams display boards you can use aftermarket LED replacements. At the moment, I have genuine displays on my system 6 setup, and my system 7 setup uses LEDs from http://wolffpactech.com

    If you want to force an example of strobe mismatching, you can run a sys6a or sys7 "05-displays" ROM while emulating a sys346 board. You will see the numbering on each display is not "7654321" but you will be able to account for all of the digits. This will not hurt the hardware.

    Also, Williams code will differ in where they actually store the values to send to the displays. For the sys7 pincoder ROMs, I used 0x1008 - 0x1019 inclusively (sys346 and 6a use 0x0008 - 0x0019). This might be the reason you are seeing things differently, though if your approach is to emulate the PIAs, the memory addresses should not matter.

    Powering up with the sys7 'show_maxcred' test you should see:

    X000427 XXXX001
    XXXX171 XXXX0NN

    Where X is blank, and NN is the first digit of the MAXIMUM CREDITS value. On a hyperball machine, after running clear_cmos, then powering up twice with flipper2, then with show_maxcred this value is "03".

    Interestingly enough, the left digits of CREDIT and MATCH are both ghosting a little garbage, but they should be blank on this test. Again, flickering and ghosting will be a function of how I wrote my display driver.

    After defaulting sys346 you should see:

    000395 XXX001
    XXX139 XXX002

    sys6a should show the same values as sys346, but on the sys7 display pattern above.

    #62 1 year ago

    I've cloned your code, and have been attempting to decipher what I see. At this point, I won't be of any use trying to actually find bugs there, but I am getting a picture of how an FPGA works, and how the code is structured to support the hardware emulation. Cool stuff!

    #63 1 year ago
    Quoted from pincoder:

    Are you able to test with genuine Williams display boards? I know some of the aftermarket bench LCD display equivalents do not always function perfectly because they take shortcuts in their design.

    I have only my own WillFA7 Diag LCD display with a self written routine which reacts to changes on display strobe and then scans bcd values to show them.
    While working fine with System346 looks like my routine has 'problems' with the way you are displaying.
    See pictures attached: while Williams do have a 'clean' strobe counting from 0$ to F$, with your rom the strobe do have 'strobes' in between
    counting 0,1,2,3,0 The bcd data is F$ while that happening, so original displays do not react on that, but my routine does

    Any chance that you change that? If it is too much work, I will try to adapt my scan routine

    disp_flash (resized).pngdisp_flash (resized).pnginterrupt_rom (resized).pnginterrupt_rom (resized).pnginterrupt rom details (resized).pnginterrupt rom details (resized).png
    #64 1 year ago

    I think you might be seeing the 08-interrupts scanning the DIP switches in PIA1_A.

    It does this by rotating the lower 4 bits of PIA1_A (which is also connected to IC6 for the display strobes) and then reading the upper 4 bits. You can verify this by running the 05-displays test as it does not scan for dip switches so the behaviour should disappear.

    With the current Pincoder ROMs, the DIP switch code is separate from the display code so in a test ROM that uses them both you will see them intermixed on the actual display strobe outputs.

    This could in fact, be why some LCD bench displays I've seen don't function properly. The one's I've seen don't use all 16 strobes. Instead, they use only 1 and then play the rest out in timing. As you can see, this only works if the strobes are purely sequential and not intermixed.

    Changing the code at this point would require blending the two sections of code so that the display strobe could be purely sequential (0-15) while effectively piggy-backing the DIP switch scans at the same time. It is a better way to go for sure and would likely speed things up a little. Unfortunately this would take some time to implement.

    Slight tangent:

    One other thing to note is that the Pincoder test ROMs do not use interrupts to service the displays (or anything else). This is to remove the dependency that the CPU chip and IRQ circuitry be functional in order to show working displays, etc. and makes troubleshooting much more reliable.

    In "08-interrupts", the interrupt routine simply tracks time passing and returns. Everything else is done in the main code. So if the displays dont show time moving along, then there is a problem with the interrupt circuits on the board, or the CPU chip itself. It also provides a way to see the "uptime" of a particular board. Faulty reset circuits and random instant electrical reboots would also not show the accumulated passage of time.

    Of course, the downside of NOT using interrupts to drive the displays is that you end up with displays that flicker if the main code isn't spending enough time refreshing the displays. In a test environment that's okay. Not so much when running game code.

    #65 1 year ago

    Also, earlier I was curious how the 08-interrupts test on your board faired against the irq and stack corruptions you are seeing.

    Since the interrupt routine in 08-interrupts is fairly light I thought it might shed some light on whether your stack code itself was causing the issue or whether it was buggy Williams code.

    Hopefully that gives you something to go on. If it would be beneficial to have some other very basic test roms created let me know and I'll see what I can do.. I could even use A15 as a trigger for your logic analyzer..

    #66 1 year ago
    Quoted from pincoder:

    This could in fact, be why some LCD bench displays I've seen don't function properly. The one's I've seen don't use all 16 strobes. Instead, they use only 1 and then play the rest out in timing. As you can see, this only works if the strobes are purely sequential and not intermixed.

    This helped My code was only reading bcd data in case PIA1_A7 changed status. I changed the code to read data
    when any of A7,A6,A5 or A4 do change status, looks better now. -> see picture
    I have counting on all displays, player 2 & 4 show a 6 digits count; player 1 & 3 show a 2 digit count, status display is fix at 0000
    I can also see in my traces a clean interrupt handling. The interrupt read ram at $7A & $7B, increments it and write it back.
    Is that OK?

    Maybe we find something by focussing on the williams selftest?
    If I understand correctly with SYS4 & 6 by pressing 'Diag' the internal selftest is executed.
    If anything is OK, the LEDs should blink twice, BUT with WillFA7 the upper LED goes ON which indicates a ram failure???
    Same behaviour on SYS3, where I need the diag mode for game adjustments ...

    Tracing at this point in time ( with upper LED ON) shows that the program is doing a loop by executing interrupt
    and going into wait mode ( WAI instruction ) at the end of interrupt.
    With a Gorgar rom coming back from wait mode, cpu reads vector at addresses $FFF8 & $FFF9 and jumping to $60EE
    do execute 'something' going back to WAI after around 260uS

    08_int (resized).png08_int (resized).pngdiag loop (resized).pngdiag loop (resized).png
    #67 1 year ago

    Yes, 0x7A and 0x7B are where the interrupt vector in 08-interrupts tracks each IRQ pulse. When it gets to 1000 then around one second has passed. 0x7C and 0x7D are incremented and 0x7A and 0x7B are reset to zero.

    In my testing of system 6, the hardware IRQs are not generated at exactly 1000 per second. In addition to that, the PIAs have the ability to inject their own IRQ pulse if they are configured to do so when they are initialized. Pincoder ROMs don't use them that way. Williams code might.

    The 4 to 16 decoder (IC6) is connected to PIA1 port A pins 0-3 so that is what needs to be checked for display updates. Depending on the DDR register, Reading bits 4-7 would only detect DIP switch settings, as long as SW2 is pressed. Writing to bits 6+7 would activate the top and bottom LEDs.

    Player 1 and 3 displays should look identical to 2 and 4. Try changing your pin tests from 4-7 to 0-3.

    In addition, on the Master Display board, IC6 and IC7 (reads BCD data) will blank a digit if the 4 bit value is A-F (Not just F). So your board should do the same just in case williams code puts out an A or something.

    I think if you implement the above changes you should get proper displays.

    What is your status display? I'm assuming that is CREDIT and MATCH. If so the zeros should be there. Let the ROM run for around 24 hours and it should change to "0101" (Number of Days is shown in each of CREDIT and MATCH).

    #68 1 year ago
    Quoted from bontango:

    .. pressing 'Diag' the internal selftest is executed.
    If anything is OK, the LEDs should blink twice, BUT with WillFA7 the upper LED goes ON which indicates a ram failure???

    I can't speak for anything about what the williams self test does. If it is a RAM failure then it must have something do to with how you are accessing and presenting values in RAM and the expected values are not presented. Does your board need to distinguish between internal CPU RAM vs. using IC13? Williams code and Pincoder code can't tell the difference as the selection is made at the hardware level.

    Also curious, for the system 7 compatibility, do you actually implement emulation for the two side-by-side 4 bit RAM chips?

    #69 1 year ago
    Quoted from bontango:

    If anything is OK, the LEDs should blink twice, BUT with WillFA7 the upper LED goes ON which indicates a ram failure???

    This is the code from Gorgar.

    sys6_nmi_ram_check.jpgsys6_nmi_ram_check.jpg

    $7BF7 selects #$20 which is LED1 = the top LED.

    #70 1 year ago
    Quoted from DumbAss:

    This is the code from Gorgar.

    thanks!
    If I interpret the code right, at test start it writes $0 to all ram addresses $0 ... $FF
    As I cannot see ram write access after pressing Diag I assume that the diag routine do fail before the ram test.
    You posted the NMI test for system7 a few days ago, do you have the sys6 code for me?
    In what order rom/ram/cmos the system is tested?

    I was also wondering if Wiliams do use any undocumented/illegal 6800 cpu instructions which may not ne supported
    by my CPU core. Do you know if Williams do that?

    #71 1 year ago
    Quoted from bontango:

    If I interpret the code right, at test start it writes $0 to all ram addresses $0 ... $FF
    As I cannot see ram write access after pressing Diag I assume that the diag routine do fail before the ram test.
    You posted the NMI test for system7 a few days ago, do you have the sys6 code for me?
    In what order rom/ram/cmos the system is tested?
    I was also wondering if Wiliams do use any undocumented/illegal 6800 cpu instructions which may not ne supported
    by my CPU core. Do you know if Williams do that?

    Yes. The code looks to write the index to the address. If you do not see any SRAM writes then the previous check is failing. That previous check is the ROM check. A ROM check fail results in the other LED (bottom) being illuminated. If you aren't seeing that then there is something else going on. The ROM check is a pretty simple check.

    The code is ROM check -> SRAM check -> CMOS check -> flash LEDs indicating success. It's not fancy or complicated.

    The code does not use any illegal instructions that I have seen but I haven't gone over the system 6 code as much as I have the system 7 code. In so far as my disassembler has the possibility to indicate illegal instructions. I think there's only one that I have found in that code that I haven't investigated to figure out if it's illegal or impossible to actually execute as code. There is data embedded within the code. There is no strict separation of code and data. This is typical for code of this era. Once virtual memory and page protections were implemented in processors, changes were made to try to strictly separate code and data so that code could be marked as (in Win32 parlance) PAGE_READONLY | PAGE_EXECUTE and data as either PAGE_READONLY or PAGE_READWRITE.

    Here is the ROM check code. As mentioned, it's not fancy or complicated.

    sys6_nmi_entry.jpgsys6_nmi_entry.jpg

    #72 1 year ago

    that helped a lot. I can see the failing romcheck and loading $10 to $2800, so I might have fallen again to this upper/lower LED confusion ...
    Anyway, now finally I have something concret to check will investigate further and let you know

    #73 1 year ago
    Quoted from bontango:

    I was also wondering if Wiliams do use any undocumented/illegal 6800 cpu instructions which may not ne supported
    by my CPU core. Do you know if Williams do that?

    For the most part the pinball manufacturers of this era that used the 6800 processor series have not used illegal instructions from what I have seen (Bally, Stern, Williams). I haven't disassembled EVERY game of course (it just seems that way sometimes...) - there are occasional hiccups in the code (Six million $ man jumps incorrectly to an illegal instruction, and galaxy has some leftover kruft that never gets executed that are illegal instructions) - but it's pretty straightforward. Space was tight but not so tight that they took advantage of the illegal instructions.

    If the illegals are well documented I think it would be worthwhile to put them in the core if they are 100% consistent across revisions - they aren't always though so I wouldn't worry too much about it. I know you're mainly working on getting the emulation going, but the bootup and interrupts, both periodic and NMI, do not use any illegal instructions.

    They all have (except for Bally) employed an interpreted language so if you are disassembling code, you will run into 6800 instructions that make no sense. Details on the stern one in my Galaxy disassembly thread, and details on the williams pinbol at Jess Askey's website: http://gamearchive.askey.org/Pinball/Manufacturers/Williams/PinBuilder/text/williams_lvl7_programming.html#compatibility

    #74 1 year ago

    Williams selftest is working now

    Reason for rom failure was that I have assigned the complete address room for SYS3..SYS7 ( 10K: $5800 ... $7FFF )
    ( two SYS7 games using 12K, but the FPGA internal ram/rom limit is around 10K )
    Roms are loaded at start from SD independent of the system type as 10K block from SD.
    In case of SYS6 I prepared the 10K block with two '2K' gaps so that it fits into the address rom
    example for Gorgar:
    copy /b ..\2K + gamerom.716 + ..\2K + green1.716 + green2.716 gorgar.rom
    For the 2K gaps I used files with almost random data, as I just renamed one of the original 2K roms.
    As the Williams rom test routine read all bytes from $6000...$7FFF and add them up it has also red and added the data from the '2K gap'
    After replacing the data in the 2K gap withall zero $00 it worked, by pressing Diag the two leds do blink twice.
    Thanks for all the help!

    Next I will try to find the reason for the $44 offset when changing data in the SYS4 & SYS6 settings menu.
    For example for setting #13 the right cmos location is $181, WillFA do store at $1C5 instead.

    So far I investigated that the cmos cell is calculated by adding $7F to the current value of B register.
    Hi byte is stored at $86 (fix $01 ) and low byte is stored at $87
    I compared to pinmame and there B register is $02 at that point in time, resulting saving at $181
    Within WillFA B register has $C3 at that point in time so it saves at $1C5 ?????
    Couldn't find the reason for that so far, any idea?

    #75 1 year ago

    Strange they test for hardware addresses that are not actually there. Also lucky that they get zeros when they do.. I don't think it's safe to assume like that.. perhaps it's also 'luck' that an FPGA will get zeros too. I should write and run a test on my system 6 board and see if those ranges always come up zero.. at any rate, glad you found it!

    Perhaps I'm wrong, but it seems you have to write code for a lot of special cases.. but I would think if you wrote code that strictly emulated each chip exactly there would be no need for special cases.. ?

    The Pincoder sys346 roms don't distinguish between 3, 4, and 6.. it's all exactly the same binary so I would think you would also be able to take advantage of that..

    Thoughts?

    #76 1 year ago
    Quoted from pincoder:

    Strange they test for hardware addresses that are not actually there. Also lucky that they get zeros when they do.. I don't think it's safe to assume like that.. perhaps it's also 'luck' that an FPGA will get zeros too. I should write and run a test on my system 6 board and see if those ranges always come up zero.. at any rate, glad you found it!

    I was thinking the same, but with this the checkroutine is much simpler: just adding all bytes and compare result with byte at address $6000
    Also I'm not sure if the reading on real hardware is $00 (its what I saw in pinmame)
    Maybe it is $FF and the 'checksum' will not change by adding 2048 times $FF ??
    Writing a rom test would be a good thing, I don't think you have a romtest at the moment?

    Quoted from pincoder:

    Perhaps I'm wrong, but it seems you have to write code for a lot of special cases.. but I would think if you wrote code that strictly emulated each chip exactly there would be no need for special cases.. ?

    As the Williams boards are (more or less) compatible at the moment the code do not differentiate between Sys3,4,6,7.
    Its just the 10K rom file which is different in how the roms are arranged. The program just takes the 10K rom and split it to the address room

    From the source:
    --------------------------
    ------------------
    -- address decoding
    ------------------
    --
    --roms 2K each
    rom1_cs <= '1' when cpu_addr(14 downto 11) = "1011" and cpu_vma='1' else '0'; --5800-5FFF
    rom2_cs <= '1' when cpu_addr(14 downto 11) = "1100" and cpu_vma='1' else '0'; --6000-67FF
    rom3_cs <= '1' when cpu_addr(14 downto 11) = "1101" and cpu_vma='1' else '0'; --6800-6FFF
    rom4_cs <= '1' when cpu_addr(14 downto 11) = "1110" and cpu_vma='1' else '0'; --7000-77FF
    rom5_cs <= '1' when cpu_addr(14 downto 11) = "1111" and cpu_vma='1' else '0'; --7800-7FFF

    ------------------
    -- ROMs ----------
    -- moved to RAM, initial read from SD
    -- one file of 10Kbyte for all Williams variants (except Star light which has to big 12KByte)
    -- mapping is done within 10KByte file
    -- address selection: read from SD when wr_rom == 1
    -- else map to address room
    wr_rom1 <= '1' when address_sd_card(13 downto 11) = "000" and wr_rom='1' else '0'; --first 2K
    wr_rom2 <= '1' when address_sd_card(13 downto 11) = "001" and wr_rom='1' else '0'; --sec 2K
    wr_rom3 <= '1' when address_sd_card(13 downto 11) = "010" and wr_rom='1' else '0'; -- third 2K
    wr_rom4 <= '1' when address_sd_card(13 downto 11) = "011" and wr_rom='1' else '0'; -- fourth 2K
    wr_rom5 <= '1' when address_sd_card(13 downto 11) = "100" and wr_rom='1' else '0'; -- fift 2K

    rom_address <=
    address_sd_card(10 downto 0) when wr_rom = '1' else
    cpu_addr(10 downto 0);
    -------------------

    #77 1 year ago
    Quoted from pincoder:

    Strange they test for hardware addresses that are not actually there. Also lucky that they get zeros when they do.. I don't think it's safe to assume like that.. perhaps it's also 'luck' that an FPGA will get zeros too. I should write and run a test on my system 6 board and see if those ranges always come up zero.. at any rate, glad you found it!

    Remember that the base "Flipper ROMs" are like the operating system and the "Game ROM"s are the custom bit for the game in question. The OS doesn't know how many of what kind of ROMs are going to be at which locations, so it has no choice but to add up the whole range and compare it to what the game says is expected for that operation.

    Unpopulated chip locations will always read $FF so it's completely safe and repeatable to do it that way. At least on the original board - I guess that's something you have to make sure your emulated hardware in the FPGA does too.

    #78 1 year ago
    Quoted from frobozz:

    Unpopulated chip locations will always read $FF so it's completely safe and repeatable to do it that way. At least on the original board - I guess that's something you have to make sure your emulated hardware in the FPGA does too.

    thx, I did change my 2K 'gap rom' from $00 to $FF and can confirm that the romtest is still working

    #79 1 year ago

    Yabba Dabba Doo! After two weeks of tracing I found the reason for the 'offset' bug

    By comparing what pinmame does (I activated the integrated disassembler) to what WillFA7 is doing
    I noticed that within the setting menu when changing entries after a 'DAA' ( decimal adjustment) command within pinmame
    there was a jump, but not with WillFA7.

    It turned out that the cpu core I'm using ( cpu68.vhd from John Kent) do have a bug and do not set the Z-Flag when accu A is zero after the DAA command. So the 'beq' command after the daa command was not 'jumping' due to the missing Z-Flag.
    ( in the settings menu $99 is added to acuu A which was $01 at that point in time. Result is $9A respective $00 after the decimal adjustment)
    After I modified the cpu core setting menue is working.

    Unfortunetaly this did not solve my System7 problems, but thats next ...

    #80 1 year ago
    Quoted from frobozz:

    Unpopulated chip locations will always read $FF so it's completely safe and repeatable to do it that way. At least on the original board - I guess that's something you have to make sure your emulated hardware in the FPGA does too.

    This is an interesting factoid. This means that any "combination" ROMs (e.g. combining 3x 4kb (512B) ROMs into a single 16kb (2kB) ROM) means that the "missing" ROM at $6600-$67FF must be filled with $FF. It also means that any further combining must fill the address gap at $6800-$6FFF with $FF.

    I went looking at the schematic for a potential reason why the read returns $FF. The ICs connected to the data bus should be high impedance output when not selected, so something has to pull the signal low or high. I could not see anything in the CPU board schematic that would do this. However, the driver board schematic has pull up resistors to keep the signal high. Since the data bus is isolated from the processor by the transceiver, this is the only place I can see that would keep the data bus bits at a known level when every other IC is output high impedance.

    If someone can explain this better, I welcome the opportunity to learn.

    #81 1 year ago
    Quoted from DumbAss:This is an interesting factoid. This means that any "combination" ROMs (e.g. combining 3x 4kb (512B) ROMs into a single 16kb (2kB) ROM) means that the "missing" ROM at $6600-$67FF must be filled with $FF. It also means that any further combining must fill the address gap at $6800-$6FFF with $FF.
    I went looking at the schematic for a potential reason why the read returns $FF. The ICs connected to the data bus should be high impedance output when not selected, so something has to pull the signal low or high. I could not see anything in the CPU board schematic that would do this. However, the driver board schematic has pull up resistors to keep the signal high. Since the data bus is isolated from the processor by the transceiver, this is the only place I can see that would keep the data bus bits at a known level when every other IC is output high impedance.
    If someone can explain this better, I welcome the opportunity to learn.

    A long time ago I dumped a system 3-4 ROM that was bad on IPDB. I padded some of the empty spaces with repeated copies of the data. Then end result was game mode worked fine, but locked up when you tried to get into the test/audit mode which I overlooked and sent out a few repaired boards with. It eventually got pointed out and corrected. I can't remember what game it was now.

    #82 1 year ago
    Quoted from barakandl:

    A long time ago I dumped a system 3-4 ROM that was bad on IPDB. I padded some of the empty spaces with repeated copies of the data. Then end result was game mode worked fine, but locked up when you tried to get into the test/audit mode which I overlooked and sent out a few repaired boards with. It eventually got pointed out and corrected. I can't remember what game it was now.

    Probably World Cup.

    Quoted from DumbAss:

    I went looking at the schematic for a potential reason why the read returns $FF.

    I assumed (i know, i know) that there were pullups somewhere to do this.

    Bally sometimes assumes in their code that this nibble is always $F (sometimes they do an INC $5101address, intending it to get say $2F and increment to $3x) - which breaks anyone that leaves the extra 5101 ram in a stern mpu200 board. I do see from the mpu200 schematics there are pullups on the data bus, so Bally probably had them as well. Other times Bally sanitizes the code, ora #$0F in there before the increment. Sometimes both styles in the same game!

    As for the checksum addition in the wms system 6 game, it's using add with carry, so presumably since every add of $FF would result in a carry (unless the source result was $00) effectively making it an add $00. And every add $00 would not result in a carry, not changing the checksum at that point. This is just off the top of my head on that, but would imply that it doesn't matter if the unused bytes are $00 or $FF? Am I completely wrong here and forgetting something about the way ADC works?

    #83 1 year ago

    Bally pulls up A0 to A8 for sure. I don't think any of the upper address have pull resistors but I added them to the replacement board so I can use HC parts in the address decoding. Half the data bus used by the 5101 has a real funky pull up to VUA+Q2 with the 150ohm pull resistor on the VUA-Q2. I guess they where worried about corruption. D0-D3 just a normal 5K pullup.

    If you run a Bally game software like Dolly Parton the two 5101s installed the displays go wonky at the least. I think you get an extra zero when starting the game. instead of game start display starting at 00 shifted to the right, its 000.

    #84 1 year ago

    Interesting to hear how the other manufacturers handled it. I'll do a quick rom and see what system 6 actually does. I'll publish it too if anybody wants to try their boards.

    #85 1 year ago
    Quoted from DumbAss:

    I went looking at the schematic for a potential reason why the read returns $FF. The ICs connected to the data bus should be high impedance output when not selected, so something has to pull the signal low or high.

    If someone can explain this better, I welcome the opportunity to learn.

    Look at the input section of TTL gates. The Williams system 7 board has a 74LS245 on the data bus at IC9. For example from the TI 74LS245 datasheet below, the 9k ohm resistor and PNP base-emitter transistor on the input will effectively pull-up the signal.
    The 6800/6802/6808/6821 have standard TTL compatible inputs and outputs, likely the ROMs too so all these inputs in parallel are helping to pull up the data bus signals.

    Another thing, an erased/blank cell in an EPROM is logic level '1'. When you program an EPROM you are only programming '0' bits. Programming 0 bits is what takes time so good practice is to leave unused blocks as FF for faster programming plus there's less chance of a failed write at faulty cells you don't need.

    TTL_Input-Output.pngTTL_Input-Output.png

    #86 1 year ago
    Quoted from slochar:

    As for the checksum addition in the wms system 6 game, it's using add with carry, so presumably since every add of $FF would result in a carry (unless the source result was $00) effectively making it an add $00. And every add $00 would not result in a carry, not changing the checksum at that point. This is just off the top of my head on that, but would imply that it doesn't matter if the unused bytes are $00 or $FF? Am I completely wrong here and forgetting something about the way ADC works?

    I had thought about this but I didn't want to expend any brain power thinking about it. Maybe this is why the code uses ADC instead of ADD?

    Quoted from Quench:

    Look at the input section of TTL gates.

    Thanks for the schooling. Makes sense. Very much appreciated. Never too old to learn something. Expiring minds want to know.

    Quoted from Quench:

    Another thing, an erased/blank cell in an EPROM is logic level '1'. When you program an EPROM you are only programming '0' bits. Programming 0 bits is what takes time so good practice is to leave unused blocks as FF for faster programming plus there's less chance of a failed write at faulty cells you don't need.

    This I did know but also appreciate the affirmation. I believe NAND flash devices operate with the same principle.

    #87 1 year ago

    After solving my sys4/sys6 issues I'm back at system7 ( Black Knight l4 rom ) tracing.
    What I found out is that even when the system inits cmos and showing "2500 4"on player1
    the system do crash a few seconds after showing "2500 4" .
    This is by either by not strobing anymore the display or by showing random numbers on the display.
    Unfortunetaly the behaviour is a bit random here.

    I would expect that beside initializing cmos range with the right values and refreshing the display to show the "2500 4" there are no other activities?!
    Any hints for me where to look best?

    #88 1 year ago
    Quoted from slochar:

    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.

    coming back to that discussion: can I assume that the SYS7 Black Knight IRQ routine is coded between $EFF7 and $F10D (rti) ?
    I saw quite a lot conditional branches in there, so from the experience I had with the missing Z-bit of 'daa' in my cpu core
    I would check the commands before the branches if they set the flags correct.

    #89 1 year ago
    Quoted from bontango:

    I saw quite a lot conditional branches in there, so from the experience I had with the missing Z-bit of 'daa' in my cpu core
    I would check the commands before the branches if they set the flags correct.

    One thing to note is that accumulator compares (CMPA/CMPB) alter the NZVC flags where the index compare (CPX) does NOT alter the C flag and alters the NV flags with a special condition note. This caught me out when I used CPX and expected the C flag to be altered like an accumulator operation. This operation is different from the 6502 where the C flag is set using CPX or CPY instructions. I guess the 6800 uses a different ALU for the index instructions.

    These things are important when executing instructions as an interpreter. When executing instructions as a JIT some of these flag operations can be optimized away.

    #90 1 year ago

    Looks like C-Flag handling with cpx is OK in cpu core, I even found a comment in the source stating that: " carry is not affected by cpx " NV Flag handling looks 'normal', what are the special condition notes you stated?

    In my traces I still see that the stackpointer goes 'out of range' ( sometimes way below $13DB ) but I'm not sure if thats the reason or the result of the crash.

    I'm also wondering about the ram with system7. Just to double check: Is it right that range $00-$FF is shared with $1000-$10FF ( in the sys7 range of $1000-$13FF ? ) In my traces I can see access to $00-$FF but never to $1000-$10FF

    btw: System7 selftest is running OK, gives me a '0' .. however after the test same 'crash' symptom as after boot
    ( I think the selftest is going to game over / attract mode after finishing ? )

    #91 1 year ago
    Quoted from bontango:

    NV Flag handling looks 'normal', what are the special condition notes you stated?

    This is actually unrelated. I looked at the ISR and there's no CPX instruction in it. It was an example of the care and attention to detail that is required when writing CPU instruction emulators.

    6800_cpx_flags_modified.jpg6800_cpx_flags_modified.jpg6800_cpx_flags_notes.jpg6800_cpx_flags_notes.jpg

    Quoted from bontango:

    I'm also wondering about the ram with system7. Just to double check: Is it right that range $00-$FF is shared with $1000-$10FF ( in the sys7 range of $1000-$13FF ? ) In my traces I can see access to $00-$FF but never to $1000-$10FF

    The schematic says the hardware (double) maps $0000-$00FF and $1000-$10FF to the same physical RAM (storage). The reason you don't see access to the $1000-$10FF range is because that takes a 3-byte instruction versus a zero-page access that takes a 2-byte instruction. Typically, if the code needs to access more than a single absolute address (typically within an unsigned 8-bit index) it will load the base address into the index register and access the absolute address as an (immediate) index off the index register. Enough accesses need to be made to offset the immediate load of the absolute address into the index register, as well as the inconvenience of not being able to use the index register for other purposes. Think of this like traditional C struct pointer dereferencing or C++ "this" dereferencing.

    The ISR has some arithmetic and bit-wise operations before conditional branching. The less frequently used instructions would be the shift and rotate instructions. If you want to look for potential errors in the instruction emulation I would focus there because they are very uncommonly used instructions. This code was originally written in assembly but modern compilers typically don't use the rotate instructions, rather limiting their use to the shift instructions. When inspecting the rotate instructions, watch carefully what they do with the carry flag. Some instruction set architectures "copy" the rotated bit into the carry (8 bits of actual rotated data). Some instruction set architectures "shift" the rotated bit into the carry and shift the carry into the bits (9 bits of actual rotated data).

    #92 1 year ago
    Quoted from DumbAss:

    The less frequently used instructions would be the shift and rotate instructions. If you want to look for potential errors in the instruction emulation I would focus there because they are very uncommonly used instructions.

    Good point, that may also the reason for the not detected 'daa' bug in a core which is around 20 years old,
    I don't think branching when a 'daa' expression is zero is a common thing?
    I checked the rol instructions, but think they are working OK.

    I'm not sure anymore if the ISR is the cause of the crash.
    I used a working Black Knight nvram data from pinmame and have at least a 'stable error situation' at the moment
    With pinmame cmos data my display start showing same data as pinmame but then adds a '9' at player 2
    and game is 'blocked'. (see picture)
    However I see still display strobes and trace showing that IRQ routine is executing.

    So showing 'high score to date' is not reached.
    I started comparing pinmame trace with WillFA code but thats a huge task.
    So far until line #8566 of my trace it is identical, at this point is has show display data (without the '9')
    and has executed two times 'code in ram at $1130'

    However the pinmame trace at the point where it shows high score 2.500.000 is at line #516615
    Need to think of some shortcuts when I do no want to look at half a million line of codes

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

    There is function that copies up to 13 bytes to $1130 and executes them as 6800 code from within pinbol.

    #94 1 year ago
    Quoted from bontango:

    Good point, that may also the reason for the not detected 'daa' bug in a core which is around 20 years old,
    I don't think branching when a 'daa' expression is zero is a common thing?
    I checked the rol instructions, but think they are working OK.
    I'm not sure anymore if the ISR is the cause of the crash.
    I used a working Black Knight nvram data from pinmame and have at least a 'stable error situation' at the moment
    With pinmame cmos data my display start showing same data as pinmame but then adds a '9' at player 2
    and game is 'blocked'. (see picture)
    However I see still display strobes and trace showing that IRQ routine is executing.
    So showing 'high score to date' is not reached.
    I started comparing pinmame trace with WillFA code but thats a huge task.
    So far until line #8566 of my trace it is identical, at this point is has show display data (without the '9')
    and has executed two times 'code in ram at $1130'
    However the pinmame trace at the point where it shows high score 2.500.000 is at line #516615
    Need to think of some shortcuts when I do no want to look at half a million line of codes [quoted image]

    Have you tried the sys7 version of init_cmos? It is also for a Black Knight.

    #95 1 year ago
    Quoted from slochar:

    There is function that copies up to 13 bytes to $1130 and executes them as 6800 code from within pinbol.

    This part should be OK, saw it two times within pinmame until HSTD is shown and same code execution within WillFA7.
    However I started to dive in Williams Macro Language to understand 'whats going on'.
    VERY cool stuff on that side, thx. for the link, will need some days to understand it ...

    Quoted from pincoder:

    Have you tried the sys7 version of init_cmos? It is also for a Black Knight.

    Yep, it worked. However for my tests I hardcoded cmos data in my program to have same data at each start of test;
    because I noticed that sometimes the crashed program overwrites cmos data, giving me erratic results from test to test

    #96 1 year ago

    System7 is working on the desk now
    It turned out that it was another bug in my CPU core, this time with interrupt handling.
    I found it by programming a flag within WillFA which turned '1' whenever the stackpointer goes lower than $1200 (which should not happen) with this I saw that the flag went high right after entering the IRQ handling.
    While IRQ handling in general worked, it destroyed the stackpointer each time the saved return address of the IRQ pointed to a 'LDS' command.
    ( see attached commented trace )
    I could solve the issue by setting the (internal) opcode to 'nop' while executing the IRQ handling within the cpu core.

    Again thanks for all the help, I would not have been able to find the bug without it!

    stack_bug (resized).pngstack_bug (resized).png
    #97 1 year ago

    I'll readily admit I can't follow most of the conversation that took place here, but I'm really excited to see you make progress on this, @bontango!

    Props to all who chimed in, too--this was a team effort

    #98 1 year ago

    Having used and been frustrated with Xilinx Vivado for some time, I really appreciate bontango work!

    #99 1 year ago
    Quoted from bontango:

    I could solve the issue by setting the (internal) opcode to 'nop' while executing the IRQ handling within the cpu core.
    Again thanks for all the help, I would not have been able to find the bug without it![quoted image]

    That's an interesting fix. Is the git repo updated with the fix? I'd like to see the changes in code

    #100 12 months ago
    Quoted from pincoder:

    Is the git repo updated with the fix?

    yes, I uploaded the new version together with the 'daa' fix and a 'tst' fix I found on opencore
    However the fix for the IRQ is only one line!
    https://github.com/bontango/WillFA7/blob/main/cpu68.vhd

    There are 100 posts in this topic. You are on page 2 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/page/2?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.