{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":24676138,"defaultBranch":"master","name":"BDD6502","ownerLogin":"martinpiper","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2014-10-01T11:36:24.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/2396609?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1617636623.94541","currentOid":""},"activityList":{"items":[{"before":"db8e03baf5b0bba20c78a9300bb06bc92312eb84","after":"84868bffff044248e1522225fb586ed0f81ae4f3","ref":"refs/heads/master","pushedAt":"2024-05-21T14:57:50.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"martinpiper","name":"Martin Piper","path":"/martinpiper","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2396609?s=80&v=4"},"commit":{"message":"Update TODO.txt","shortMessageHtmlLink":"Update TODO.txt"}},{"before":"052b55b877648326c74037835f6532a960ce60ae","after":"db8e03baf5b0bba20c78a9300bb06bc92312eb84","ref":"refs/heads/master","pushedAt":"2024-05-19T03:12:11.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"martinpiper","name":"Martin Piper","path":"/martinpiper","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2396609?s=80&v=4"},"commit":{"message":"Then accounting for transient values expect the next line to contain \"d=PTPA2 | PT_PC | $00000055\"","shortMessageHtmlLink":"Then accounting for transient values expect the next line to contain …"}},{"before":"6f29d3b2351f53048a7c58f85cdca1e7569dc4ef","after":"052b55b877648326c74037835f6532a960ce60ae","ref":"refs/heads/master","pushedAt":"2024-05-18T14:03:54.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"martinpiper","name":"Martin Piper","path":"/martinpiper","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2396609?s=80&v=4"},"commit":{"message":"Update TODO.txt","shortMessageHtmlLink":"Update TODO.txt"}},{"before":"434d0b2b9f3ae22432f189030af594c142301408","after":"6f29d3b2351f53048a7c58f85cdca1e7569dc4ef","ref":"refs/heads/master","pushedAt":"2024-05-18T08:52:38.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"martinpiper","name":"Martin Piper","path":"/martinpiper","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2396609?s=80&v=4"},"commit":{"message":"When ignoring empty lines","shortMessageHtmlLink":"When ignoring empty lines"}},{"before":"ee0778a7af82cefa310890ae0013d0efb063f1a7","after":"434d0b2b9f3ae22432f189030af594c142301408","ref":"refs/heads/master","pushedAt":"2024-05-18T03:28:20.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"martinpiper","name":"Martin Piper","path":"/martinpiper","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2396609?s=80&v=4"},"commit":{"message":"Add syntax: When ignoring lines that contain \"ignore\"","shortMessageHtmlLink":"Add syntax: When ignoring lines that contain \"ignore\""}},{"before":"2a8bc2ab0d90e853fae308fe13a54669695f7e8e","after":"ee0778a7af82cefa310890ae0013d0efb063f1a7","ref":"refs/heads/master","pushedAt":"2024-03-23T08:11:03.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"martinpiper","name":"Martin Piper","path":"/martinpiper","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2396609?s=80&v=4"},"commit":{"message":"Update demos to use RGB565","shortMessageHtmlLink":"Update demos to use RGB565"}},{"before":"8dc90d4bd7e2a32e012fafd49c889943583eea27","after":"2a8bc2ab0d90e853fae308fe13a54669695f7e8e","ref":"refs/heads/master","pushedAt":"2024-03-18T08:51:25.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"martinpiper","name":"Martin Piper","path":"/martinpiper","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2396609?s=80&v=4"},"commit":{"message":"Add: Given set the video display with 8 palette banks","shortMessageHtmlLink":"Add: Given set the video display with 8 palette banks"}},{"before":"23554f480bdb4d5f7952de1b4839b1e99cb3391b","after":"8dc90d4bd7e2a32e012fafd49c889943583eea27","ref":"refs/heads/master","pushedAt":"2024-03-16T07:39:10.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"martinpiper","name":"Martin Piper","path":"/martinpiper","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2396609?s=80&v=4"},"commit":{"message":"Add: Given set the video display to RGB colour 5 6 5\n\nPreparation work for upgrading the video hardware colour depth.","shortMessageHtmlLink":"Add: Given set the video display to RGB colour 5 6 5"}},{"before":"2717d36e23439aae58ec28847c9e26d181590f9e","after":"23554f480bdb4d5f7952de1b4839b1e99cb3391b","ref":"refs/heads/master","pushedAt":"2024-03-16T07:16:56.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"martinpiper","name":"Martin Piper","path":"/martinpiper","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2396609?s=80&v=4"},"commit":{"message":"Improved the palette emulation by maintaining real palette memory and the palette cached RGB value separately.","shortMessageHtmlLink":"Improved the palette emulation by maintaining real palette memory and…"}},{"before":"b40c5a3e608c6181046a0790711c341aa7ed750d","after":"2717d36e23439aae58ec28847c9e26d181590f9e","ref":"refs/heads/master","pushedAt":"2024-02-17T11:55:42.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"martinpiper","name":"Martin Piper","path":"/martinpiper","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2396609?s=80&v=4"},"commit":{"message":"TODO","shortMessageHtmlLink":"TODO"}},{"before":"2086f0a0b1c7f61f84363039f27a0d6b79b6f661","after":"b40c5a3e608c6181046a0790711c341aa7ed750d","ref":"refs/heads/master","pushedAt":"2024-02-04T07:25:27.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"martinpiper","name":"Martin Piper","path":"/martinpiper","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2396609?s=80&v=4"},"commit":{"message":"Add extra PropertiesResolution.resolveInput for some steps","shortMessageHtmlLink":"Add extra PropertiesResolution.resolveInput for some steps"}},{"before":"aae8dd11c185f005f2512c69b45a23e88f816c92","after":"2086f0a0b1c7f61f84363039f27a0d6b79b6f661","ref":"refs/heads/master","pushedAt":"2024-02-01T11:35:10.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"martinpiper","name":"Martin Piper","path":"/martinpiper","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2396609?s=80&v=4"},"commit":{"message":"Given set the variable \"test.cycles\" equal to the cycle count","shortMessageHtmlLink":"Given set the variable \"test.cycles\" equal to the cycle count"}},{"before":"5a7cd551c48a2033ab0773dc0d97cc66fd49dd12","after":"aae8dd11c185f005f2512c69b45a23e88f816c92","ref":"refs/heads/master","pushedAt":"2023-11-04T13:57:26.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"martinpiper","name":"Martin Piper","path":"/martinpiper","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2396609?s=80&v=4"},"commit":{"message":"Update @TC-9-95 expected data","shortMessageHtmlLink":"Update @TC-9-95 expected data"}},{"before":"109ca6de6dee2fdac8ddca6c379dccfbe98b6446","after":"5a7cd551c48a2033ab0773dc0d97cc66fd49dd12","ref":"refs/heads/master","pushedAt":"2023-11-04T07:49:20.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"martinpiper","name":"Martin Piper","path":"/martinpiper","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2396609?s=80&v=4"},"commit":{"message":"support Sprites V9.5 layer, which includes the option to clock the pixels at a different clock rate.","shortMessageHtmlLink":"support Sprites V9.5 layer, which includes the option to clock the pi…"}},{"before":"f3026eec6ae15d2b8b2d32823542fc69fadbd797","after":"109ca6de6dee2fdac8ddca6c379dccfbe98b6446","ref":"refs/heads/master","pushedAt":"2023-10-20T03:22:41.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"martinpiper","name":"Martin Piper","path":"/martinpiper","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2396609?s=80&v=4"},"commit":{"message":"Updating the hardware test for the latest display version","shortMessageHtmlLink":"Updating the hardware test for the latest display version"}},{"before":"0586a312f7f3018f9bcbb766dc90494244d3790d","after":"f3026eec6ae15d2b8b2d32823542fc69fadbd797","ref":"refs/heads/master","pushedAt":"2023-10-15T10:17:22.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"martinpiper","name":"Martin Piper","path":"/martinpiper","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2396609?s=80&v=4"},"commit":{"message":"Tests file writing syntax","shortMessageHtmlLink":"Tests file writing syntax"}},{"before":"2f9b5d8dbc1e010de1f8676c3947b93b9d2a314b","after":"0586a312f7f3018f9bcbb766dc90494244d3790d","ref":"refs/heads/master","pushedAt":"2023-10-06T08:27:41.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"martinpiper","name":"Martin Piper","path":"/martinpiper","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2396609?s=80&v=4"},"commit":{"message":"C64 and Video display should open side by side","shortMessageHtmlLink":"C64 and Video display should open side by side"}},{"before":"32954aefed0ac0021fa6f70ecd4a423f8fd409bd","after":"2f9b5d8dbc1e010de1f8676c3947b93b9d2a314b","ref":"refs/heads/master","pushedAt":"2023-10-06T08:12:59.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"martinpiper","name":"Martin Piper","path":"/martinpiper","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2396609?s=80&v=4"},"commit":{"message":"Fix DisplayC64 null references if there is no CHARGEN ROM attached","shortMessageHtmlLink":"Fix DisplayC64 null references if there is no CHARGEN ROM attached"}},{"before":"0d33c5c3ed3faeab5af5afd05ad0f9be1840d68c","after":"32954aefed0ac0021fa6f70ecd4a423f8fd409bd","ref":"refs/heads/master","pushedAt":"2023-09-27T00:59:37.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"martinpiper","name":"Martin Piper","path":"/martinpiper","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2396609?s=80&v=4"},"commit":{"message":"Given audio mix 85\n\nThis adds a left/right mix of 33% (0.33333 * 256 = 85)","shortMessageHtmlLink":"Given audio mix 85"}},{"before":"ba7b3e496720f807df7016cce4118b31edd5d5ed","after":"0d33c5c3ed3faeab5af5afd05ad0f9be1840d68c","ref":"refs/heads/master","pushedAt":"2023-09-26T13:01:23.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"martinpiper","name":"Martin Piper","path":"/martinpiper","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2396609?s=80&v=4"},"commit":{"message":"Add syntax to handle regularly triggered IRQ: Given add C64 regular IRQ trigger of \"100000\" cycles","shortMessageHtmlLink":"Add syntax to handle regularly triggered IRQ: Given add C64 regular I…"}},{"before":"a8210d4e82e4d0bb9e68b025ee988cee3b562aaf","after":"ba7b3e496720f807df7016cce4118b31edd5d5ed","ref":"refs/heads/master","pushedAt":"2023-09-26T08:23:34.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"martinpiper","name":"Martin Piper","path":"/martinpiper","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2396609?s=80&v=4"},"commit":{"message":"Update BDD6502.iws","shortMessageHtmlLink":"Update BDD6502.iws"}},{"before":"204721c7bc58ec26fb6a727e0ac957e514ffb966","after":"a8210d4e82e4d0bb9e68b025ee988cee3b562aaf","ref":"refs/heads/master","pushedAt":"2023-09-26T08:23:10.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"martinpiper","name":"Martin Piper","path":"/martinpiper","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2396609?s=80&v=4"},"commit":{"message":"Update TODO.txt","shortMessageHtmlLink":"Update TODO.txt"}},{"before":"4d9b634b5525585e5f8348a26e60d18ba423238b","after":"204721c7bc58ec26fb6a727e0ac957e514ffb966","ref":"refs/heads/master","pushedAt":"2023-09-24T13:42:01.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"martinpiper","name":"Martin Piper","path":"/martinpiper","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2396609?s=80&v=4"},"commit":{"message":"TODO","shortMessageHtmlLink":"TODO"}},{"before":"a1b06ddf3ad48d03de5d531512a0cb352d5253e6","after":"4d9b634b5525585e5f8348a26e60d18ba423238b","ref":"refs/heads/master","pushedAt":"2023-09-24T07:20:09.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"martinpiper","name":"Martin Piper","path":"/martinpiper","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2396609?s=80&v=4"},"commit":{"message":"Fixed Demo9 palette issues","shortMessageHtmlLink":"Fixed Demo9 palette issues"}},{"before":"a8cb9f86d3377ded1a6308710ad8c4e13215ac1a","after":"a1b06ddf3ad48d03de5d531512a0cb352d5253e6","ref":"refs/heads/master","pushedAt":"2023-09-23T13:11:17.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"martinpiper","name":"Martin Piper","path":"/martinpiper","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2396609?s=80&v=4"},"commit":{"message":"Update TODO.txt","shortMessageHtmlLink":"Update TODO.txt"}},{"before":"56cd3cd01dc075e0396355543736490fdf52fdf3","after":"a8cb9f86d3377ded1a6308710ad8c4e13215ac1a","ref":"refs/heads/master","pushedAt":"2023-09-20T13:42:17.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"martinpiper","name":"Martin Piper","path":"/martinpiper","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2396609?s=80&v=4"},"commit":{"message":"Update TODO.txt","shortMessageHtmlLink":"Update TODO.txt"}},{"before":"b6508def12bb7e83c68162d44b2951fb4b5d09e1","after":"56cd3cd01dc075e0396355543736490fdf52fdf3","ref":"refs/heads/master","pushedAt":"2023-09-20T11:05:16.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"martinpiper","name":"Martin Piper","path":"/martinpiper","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2396609?s=80&v=4"},"commit":{"message":"; Done items  Added: Given I am using C64 processor port options \tThis stops writes to the IO registers from going to RAM    * Add emulated BombJack display \thttps://github.com/martinpiper/BombJack/blob/master/README.md \tSprites notes \t\t0x = far left visible screen pixel \t\tDone 0y = 16x16 Top of the sprite just below the bottom edge of the visible screen \t\tDone 0y = 32x32 Middle horizontal part of the sprite just below the bottom edge of the visible screen \tAdd 32x32 sprites 9a00-9a01 (largeSprite) \t\tDone - Check the hardware for how the inclusive register really works with regards to using sprite update slots \t\t\t0-3\t No 32x32 \t\t\t0-4\t Sprite 0 is 32x32, sprite 1 is not drawn, sprites 2 onwards are drawn \t\t\t0-5\t Sprite 0,2 is 32x32, sprite 1,3 is not drawn, sprites 4 onwards are drawn \t\t\t0-6\t Sprite 0,2,4 is 32x32, sprite 1,3,5 is not drawn, sprites 6 onwards are drawn \t\t\t0-7\t Sprite 0,2,4,6 is 32x32, sprite 1,3,5,7 is not drawn, sprites 8 onwards are drawn  \t\t\t1-4\t Sprite 0 is 32x32, sprite 1 is not drawn, sprites 2 onwards are drawn \t\t\t2-4\t Same \t\t\t3-4\t Same \t\t\t4-4\t No 32x32 \t\t\t4-5\t Sprites 0-1 are normal, Sprite 2 is 32x32, Sprite 3 is not drawn, sprites 4 onwards are drawn  \t\t\t5-4\t Sprites 0-1 are normal, Sprite 2 is 32x32, Sprite 3 is not drawn, sprites 4 onwards are drawn \t\t\t5-5\t No 32x32 \t\t\t6-5\t Sprites 0-3 are normal, Sprite 4 is 32x32, Sprite 5 is not drawn, sprites 6 onwards are drawn \t\t\t7-5\t Sprites 0-3 are normal, Sprite 4,6 is 32x32, Sprite 5,7 is not drawn, sprites 8 onwards are drawn  \t\t\t1-5\t Sprite 0,2 is 32x32, sprite 1,3 is not drawn, sprites 4 onwards are drawn \t\t\t2-5\t Same   \t\t\tDoes it skip the next sprite? \t\t\t\tYes \t\t\tWhat about the odd numbers sprites for the ranges? \t\t\t\tNo, not the lines into 5R 5S \t\tAlso the sprite frame, does it multiply the sprite frame to ensure it is aligned? \t\t\tYes, it multiplies by 4 \t\t\tWhat is the sprite layout? \t\t\t\t01 \t\t\t\t23 \tDo sprites off the far right appear on the left? \t\tYes \tDo sprites off the bottom appear on the top? \t\tNo. \tDone - Add full height mode (fullHeightSprite)    * Emulated hardware display \tWhen allocating layers, make the address and addressEx configurable \tTODO: Address configs for addressEx=0x01 need to respect the INRAMSEL1 groups 0x8000 0x8800 0x9000 0x9800 ... 0xb800 as these used for selection on each board \t\tVideo board uses fixed address, not configurable.  \t\t \t\t * To correctly handle the \"lo ENABLEPIXELS (with no border flags)\" at 0x189H \tAnd to handle the hardware plane shifting, which introduces an 8 pixel delay \tThe tiles and chars need to latch the Y position at the start of their reads for each tile/char 8 pixel span \t* Sprites also needed this fix, actually it was the sprite span pixel read and clear that gave the hint about the latch \t* See: latchedDisplayV \t* The mode7 layer does not have this problem because it maintains its own pixel clocks from hsync and vsync    * Continue adding syntax to support the other video layers \tfeatures\\TestVideoHardware.feature    * Detect when the 24 bit bus is held with an address for an extended number of cycles without data being written \tNo need now, the hardware automatically resets the bus a while after the byte is written if another write has not been started    * displayBombJack.isVsyncTriggered \tThe $dd0d value is reading the logic level of vsync in the display, it technically doesn't need the reset logic \tHowever the vsync wait will need a wait for \"not vync\" if a wait for vsync is issued too quickly after the first wait    * Optional syntax to limit the speed to XX FPS for video display   * Add arrows+ctrl as joystick1 ($dc00) for the video display window    * Output the software bus writes so that the Proteus simulator can use. Will need to detect waits for vsync or log x/y pos for writes    * Using target/debugData.txt the real hardware isn't displaying the high mode7 characters? \t* Mode7Regs2Size and Mode7Regs3Size are wrong, causing strange memory overwrites \t* Verified, by filling map.bin, that tile $02 and $22 are actually rendered \t* The palette used in the tile was the same as the background colour, so it was \"invisible\". \t* However the palette was being written strangely by the contention test code  \t \t * Twiddle the mode7 HV flips to align them with tiles    * The java video hardware test mode output debug file does not quite render correctly on the hardware \tThe raster bars and perspective mode7 part is alternating every frame. Probably something to do with the output displayV not quite catching up properly \tInvestigate if the \"w$ff01ff00,$ff019000\" is not being caught correctly \tIt seems waiting for the last line and trying to do all the updates it not working out timing wise \t\tRemoving the wait for line $ff and moving the sprite update to just after the vsync wait worked \t* TODO: Investigate, do we want to want for -ve _VSYNC or -ve VBLANK as it is currently going into the digital data simulator? \t\tLook at when the better, earlier, timing is just off the bottom of the screen \t\t\tVBLANK is better \t\t* The BDD6502 emulation will need to align the wait to vsync or vblank of course, to match with what the simulator does \t* _VBLANK checking aligned with simulation and emulation  \t \t * Extract memory bus interface for future expansion    * Add audio expansion prototype \tFirst single channel sound is working at the correct sample rate \tMultiple channel is also working \t* Attempt to convert a small mod/xm \t\thttp://www.retrospekt.com.au/2020/05/tiny-music-a-massive-curated-collection-of-music-in-mod-xm-s3m-other-formats/ \t\thttps://www.dropbox.com/sh/yyxyrkin9uj76ie/AABYa381WWs8KXwsIIYo4_q7a?dl=0 \t\tNeed to find an up to 8 channel file that will fit within 64K for samples (without down sampling) \t\tWithout too many complex voice controls would also help \t\tPotential music: \t\t\t**4 channels: C:\\Users\\Martin Piper\\Downloads\\tiny music\\mods\\artists\\h0ffman\\H0ffman - Freerunner.mod \t\t\t4 channels: C:\\Users\\Martin Piper\\Downloads\\tiny music\\mods\\artists\\mortimer twang\\Mortimer Twang - No Sellout.mod \t\t\t4 channels: C:\\Users\\Martin Piper\\Downloads\\tiny music\\mods\\artists\\mygg\\Mygg - Techno Focus.mod \t\t\t8 channels: C:\\Users\\Martin Piper\\Downloads\\tiny music\\mods\\artists\\zabutom\\Zabutom - Godsends.xm \t\t\t*4 channels: C:\\Users\\Martin Piper\\Downloads\\tiny music\\mods\\various\\4Mat - One Bullet Symphony.xm  \t\tPotential java libs for parsing and converting to semi-optimised 6502 suitable format: \t\t\t* http://www.javamod.de/ \t\t\t\thttp://www.javamod.de/javamod.html  \t\t\tcd /d C:\\Users\\Martin Piper\\Downloads\\ \t\t\tjava -cp ./javamod.jar de.quippy.javamod.main.CommandLine \"C:\\Users\\Martin Piper\\Downloads\\tiny music\\mods\\artists\\h0ffman\\H0ffman - Freerunner.mod\" \t\t\tProTracker mod with 31 samples and 4 channels using Protracker frequency table \t\t\tLoader code: \t\t\t\tC:\\Users\\Martin Piper\\Downloads\\javamod-source\\source\\de\\quippy\\javamod\\multimedia\\mod\\loader\\tracker\\ProTrackerMod.java \t\t\tPlayer code: \t\t\t\tC:\\Users\\Martin Piper\\Downloads\\javamod-source\\source\\de\\quippy\\javamod\\multimedia\\mod\\ModMixer.java \t\t\t\t\tstartPlayback() \t\t\t\t\tMight be able to stub out openAudioDevice() and writeSampleDataToLine() and let it parse the file to get info from modMixer.mixIntoBuffer(LBuffer, RBuffer, bufferSize); \t\t\t\tC:\\Users\\Martin Piper\\Downloads\\javamod-source\\source\\de\\quippy\\javamod\\multimedia\\mod\\mixer\\BasicModMixer.java \t\t\t\t\tmixIntoBuffer(final int[] leftBuffer, final int[] rightBuffer, final int count) \t\t\t\t\t\tmixChannelIntoBuffers(final int[] leftBuffer, final int[] rightBuffer, final int startIndex, final int endIndex, final ChannelMemory actMemo) \t\t\t\t\t\tUses:\tC:\\Users\\Martin Piper\\Downloads\\javamod-source\\source\\de\\quippy\\javamod\\multimedia\\mod\\mixer\\ProTrackerMixer.java \t\t\t\t\t\t\t\tC:\\Users\\Martin Piper\\Downloads\\javamod-source\\source\\de\\quippy\\javamod\\multimedia\\mod\\mixer\\BasicModMixer.java \t\t\t\t\t\t\t\t\tChannelMemory \t\t\t\t\tdoTickEvents() \t\t\t\t\t\tPotentially more interesting for extracting note events \t\t\t\t\t\t\tYes definitely a lot more interesting, might even be possible to just call this in a loop to quickly get all the info \t\t\t\tC:\\Users\\Martin Piper\\Downloads\\javamod-source\\source\\de\\quippy\\javamod\\multimedia\\mod\\mixer\\ProTrackerMixer.java \t\t\t\t\t\tdoRowEffects() \t\t\tSome options for export here: \t\t\t\tmixIntoBuffer \t\t\t\t\tCan export all relevant changes in ChannelMemory \t\t\t\t\tBy modifying mixChannelIntoBuffers() \t\t\t* First pass of importing music works, repeating samples are needed, many volume and pitch updates etc are missing. \t\t\t\tThe sample frequency conversion (// Convert internal frequency to hardware values) seems to be correct \t\t\t\t\tjava -cp ./javamod.jar de.quippy.javamod.main.CommandLine \"C:\\Users\\Martin Piper\\Downloads\\_nice_outfit_.mod\"    * AudioExpansion could probably do with a loop address and loop length to be used after the first values \tCould use a flip-flop to hold the state, which is reset when high length is written. This obviously adds complexity though.    * Add kMusicCommandDefineSample with index, then remove duplicate sample data from kMusicCommandPlayNote \tCurrently: \"C:\\Users\\Martin Piper\\Downloads\\asikwp_-_twistmachine.mod\" \t\t3 m 20s in 127,487 bytes \t\tAfter writing common sample data with kMusicCommandSetSampleData: 61,766 bytes  \t\t \t\t * Added audio hardware syntax and test code \tThe MemoryBus architecture is also expansion aware.    * Continue MusicPoll with jsr DecompressMusic_GetNextByte \tProcess the music events kMusicCommandWaitFrames etc    * Find out why when running from jar the video display slows down. \tIt's almost like not enough pixels get calculated? \t* Print the number of instructions elapsed per video display frame \tHmm Oracle java is slowing down, but this java does not: \"C:\\Users\\Martin Piper\\.jdks\\corretto-1.8.0_252\\bin\\java.exe\" \t\thttps://aws.amazon.com/corretto/faqs/ is better performance than Oracle java \t\tOracle java sucks \t\t\t1>Rendered FPS = 48 frameDelta = 535 period=1001 instructionsThisPeriod=610032 instructionsPerFrame=10157 instructionsShortfall=2515 \t\t\tinstructionsThisPeriod=610032 \t\t\tnumber of emulated 6502 instructions in 1001 milliseconds \t\t\tso .6 MHz \t\tsame jar with Corretto java: \t\t\t1>Rendered FPS = 60 frameDelta = 1 period=1001 instructionsThisPeriod=3463955 instructionsPerFrame=57674 instructionsShortfall=-45002 \t\t\t5.6 times faster \t* QuickDrawPanel::fastSetRGB() created to optimise image drawing further, this is to fix slowdown when using Oracle java compared to the much faster Corretto    * Output raw sample bytes for debug playback and comparison with the hardware \te.g. \"C:\\Users\\Martin Piper\\Downloads\\ffmpeg-20200422-2e38c63-win64-static\\ffmpeg-20200422-2e38c63-win64-static\\bin\\ffplay.exe\" -f u8 -channels 2 -ar 25000 c:\\work\\C64\\VideoHardware\\target\\debugchannel.pcmu8 \te.g. \"C:\\Users\\Martin Piper\\Downloads\\ffmpeg-20200422-2e38c63-win64-static\\ffmpeg-20200422-2e38c63-win64-static\\bin\\ffplay.exe\" -f u8 -channels 2 -ar 25000 C:\\Work\\BDD6502\\target\\debugchannel.pcmu8    * Emulation will need to match hardware design which now has stereo output    * Force plane ordering, including a plane that is configured to output a specific pixel colour (to emulate poking wires into the header) \t* Tile layer background pixel transparency check. Layer should use specific plane.     * In the hardware simulation: If the sprites layer is the last layer, the sprite's x position seems to update the colour information for the whole vertical strip \tThis makes sense since the full height sprite flag has consistent colour and comes from the colour read. \tThe bit planes shifters wil be emitting zeros since they will not load the sprite data based on the vertical position test. \tThe emulation needs to be updated to reflect this. Currently the emulation does not write colour inforation if the sprite vertical portion is out of range.    * Full height sprites with 32x32 mode enabled, should not display repeated 32x32 sprite data chunks, they should show 32x16 sprite data \tAccording to the simulation from bus data output by features\\TestVideoHardware Chars Sprites.feature    * spriteIndexReJig is used to adjust the sprite reading schedule to that of the hardware    * Chars V4.0 emulation update to match schematic    * Emulate C64 timer to allow the video clock (12.096M) to drive the timer clocks \tA use case is where the C64 sets a timer to count the vertical raster position after the vsync signal is detected \t\tPixel clock = 12.096M / 2 = 6048000 Hz \t\tThe line length is 384 pixels, which gives 15750 Hz or 0.063492063492063 ms or 6.349206349206349e-5 seconds \t\tC64 CyclesPerSecondPALC64\t= 985248 Hz \t\t\tWhich means 985248 (clocks per second) / 15750 (line length from video) = 62.56 clocks per line \t* Added Video_StartRasterTimers \t\t* Easiest route will be to have a faked timer for the emulation that is setup to provide values like those in the hardware, but ignores the C64 CIA timer code setup values    * Moved display enable/border/priority registers to video generation logic    * Handle 16 colour mode for new hardware revision    * Adding an APU means \"a user port to 24 bit bus is installed\" and \"a new audio expansion\" will need to cooperate since it's possible the APU drive the sound board \tThis means all display/audio layers will need to get their memory from the APU, not the user port \t* The audio and display layer syntax can be re-ordered to be after the user port and APU syntax \t* com.bdd6502.DisplayBombJack.calculatePixel will need a callback to an optional APU    * Tidy up all the \"gotByte & 0xff\" rubbish. Make it an accessor that returns an int ready for registers to use    * APU: Debug display, configurable via syntax (and property) to display \tInstruction hex, binary flags, text flags \tPC, registers, and small memory dump for the various address registers     * de.quippy.javamod.multimedia.mod.ModMixer.fastExport add option to scale the samples (and their frequencies) to fit them into a target memory size (like 64K) \tWill need a lower sample threshold size to avoid shrinking \"chip sound\" samples \tde.quippy.javamod.multimedia.mod.mixer.BasicModMixer.exportSample \tThe sample scaling factor can also be calculated in here since exportSample() is called before the first usage of this sample \t\tThen kMusicCommandPlayNote can include the scaling factor    * Improved music data compression with intensive searching * com.bdd6502.CompressData add option to search for the best \"bestLen > 6\" value to use, since there can be better savings when using a longer threshold.    * Syntax for \"add a Chars V4.0 layer\" needs to include scrolling registers, tests will need to use new data. Create a larger source image for this and create new output data. \tOld small screen image conversion: oldbridge char screen with rgbfactor \tTODO: Need to emulate the bad char definition reads with certain scroll values     * Various music conversion command lines. File from https://modarchive.org/ : \t* Volume only? Not for this tune \tjava -Dmusic.volume=1 -jar target\\BDD6502-1.0.9-SNAPSHOT-jar-with-dependencies.jar --exportmod \"C:\\Users\\Martin Piper\\Downloads\\cream_of_the_earth.mod\" \"target/exportedMusic\" 65535 100626 \tjava -Dmusic.volume=1 -jar target\\BDD6502-1.0.9-SNAPSHOT-jar-with-dependencies.jar --exportmod \"C:\\Users\\Martin Piper\\Downloads\\lotus2-title.mod\" \"target/exportedMusic\" 7 8 \tjava -Dmusic.volume=1 -jar target\\BDD6502-1.0.9-SNAPSHOT-jar-with-dependencies.jar --exportmod \"C:\\Users\\Martin Piper\\Downloads\\intro_01.mod\" \"target/exportedMusic\" 7 8 \tjava -Dmusic.volume=1 -jar target\\BDD6502-1.0.9-SNAPSHOT-jar-with-dependencies.jar --exportmod \"C:\\Users\\Martin Piper\\Downloads\\turrican.mod\" \"target/exportedMusic\" 65535 88560 \t* Problems with repeating? Or new note detection? newInstrumentSet \tjava -Dmusic.volume=1 -jar target\\BDD6502-1.0.9-SNAPSHOT-jar-with-dependencies.jar --exportmod \"C:\\Users\\Martin Piper\\Downloads\\blood_money_title.mod\" \"target/exportedMusic\" 65535 155920 \t\t* Fixed: The \"aktMemo.newInstrumentSet = true;\" needed to be inside the \"element.getInstrument()>0\" check. Doh! \tjava -Dmusic.volume=1 -jar target\\BDD6502-1.0.9-SNAPSHOT-jar-with-dependencies.jar --exportmod \"C:\\Users\\Martin Piper\\Downloads\\speedbal.mod\" \"target/exportedMusic\" 65535 151832 \t* Volume only? SotB fixed by kMusicCommandAdjustVolume. But it does cause large files and lots of clicking. Needs a better \"instrument active\" check before it can be used. \tjava -Dmusic.volume=1 -jar target\\BDD6502-1.0.9-SNAPSHOT-jar-with-dependencies.jar --exportmod \"C:\\Users\\Martin Piper\\Downloads\\shadowofthebeast.mod\" \"target/exportedMusic\" 1 1 \tjava -Dmusic.volume=1 -jar target\\BDD6502-1.0.9-SNAPSHOT-jar-with-dependencies.jar --exportmod \"C:\\Users\\Martin Piper\\Downloads\\outrun_intro.mod\" \"target/exportedMusic\" 1 3 \tjava -Dmusic.volume=1 -jar target\\BDD6502-1.0.9-SNAPSHOT-jar-with-dependencies.jar --exportmod \"C:\\Users\\Martin Piper\\Downloads\\Shadow of the Beast (1)\\Beast1_2.mod\" \"target/exportedMusic\" 65535 71268 \tjava -Dmusic.volume=1 -jar target\\BDD6502-1.0.9-SNAPSHOT-jar-with-dependencies.jar --exportmod \"C:\\Users\\Martin Piper\\Downloads\\xenon2.mod\" \"target/exportedMusic\" 65535 325226   * Added music conversion detection of frequency change, which vastly improves playback    * Music conversion, just volume change detection needed?    * Merge event and channel \tChannel low nybble \tEvent high nybble    * Excessive clicking when starting a voice fixed. Funnily enough this wasn't in the hardware, but was a fault of the emulation \tValidated in hardware and emulation    * Music conversion: \"C:\\Users\\Martin Piper\\Downloads\\SOTB_Musiques_Amiga\\SOTB - TITLE.mod\" \tFor some reason it isn't exporting even though this does play: \t\tjava -cp \"C:\\Users\\Martin Piper\\Downloads\\javamod.jar\" de.quippy.javamod.main.CommandLine \"C:\\Users\\Martin Piper\\Downloads\\SOTB_Musiques_Amiga\\SOTB - TITLE.mod\"    * Not needed, since layer order register is included in V5.0 \t* To use the VideoHardware debug output, the hardware last two layers need to be swapped. \t\tPerhaps add a switch selector for different layer priorities into the layer select to allow runtime configuration? \t\tExtra (but disabled and not placed) logic has been added to the video layer     * Remove System.getProp* usage inside time critical routines    * Create 6502 remote debug TCP interface. Enough for the VICEPDBMonitor to work.     When enable remote debugging     And wait for debugger connection     And wait for debugger command   * Improved remote debug single stepping    * Added APU register remote debug output, if it's enabled    * Remote debugger commands like next / step / return do not need to wait for the textual reply before completing the command \tThe replies happen when the CPU next stops when sendDebuggerUpdate is true     * kAPU_SkipIfEQ needs to check the data select is stable from the previous cycle to ensure the logic operates on a stable value    * Need kAPU_InternalMEWR in BDD6502    * Add remote debugger single step option for APU \tPerhaps a command to switch between 6510 CPU and APU for the debugger next/step/etc commands \tCode reorganised \"handleSuspendLoop(remoteDebugger , RemoteDebugger.kDeviceFlags_CPU);\" to allow kDeviceFlags_CPU and kDeviceFlags_APU to suspend execution \t* This will allow the APU to have \"step out\" to run until the next matching waitHV \t* \"Step over\" and \"step in\" are basically the same as there are no JSR equivalent instructions \tNote in the glue code \"remoteDebugger.isCurrentDevice(RemoteDebugger.kDeviceFlags_CPU)\", using kDeviceFlags_APU will let the APU detect when a command is intended for it instead of the CPU \tCommands to switch APU and 6510: \t\tcpu apu \t\tcpu 6502     * Reset frame catch up times while debugging   Disable sound output    * While debugging with steps have the option of clearing the screen data from the current pixel position to show the newly rendered data in the display \tOr highlight the current position in the window with the previous frame data \tOr clear the entire display data \tDone - Hitting the next step (or break) force redraws the window, basically    * When disassembling, or dumping, take into account the current device and provide APU information when needed \tDone APU disassembly \tDone: Disassembly address in APU mode needs to use the APU PC, not the 6502 PC \t\tNote the \"before address\" fetched can be smaller that for 6502 \t\tAlso the source disassembly can use the label APUData_Start as an offset if it is available. Filter by the label's zone when in APU mode? \t\t\tAllow an optional offset in the debugger to support multiple chunks of APU code as source, or filter by the label's zone?     * displayV changes in simulation at displayH=0x180 \t* This is also at MSB displayH, of course \t* Fix emulation to reflect this (it changes at 0x188 currently) \t\t* Look for \"//        if (displayH == 0x180) {\" \t* Fix Sprite2 logic \t* However, another issue is that at 0x180 the real hardware displays the last eight pixels of the previous line... \t* Schematic will need a compatator for 0x188, could make it a latch in the register space and variable with a comparator... \t* Could also use a configurable \"use start line\" value for the span draw. This would be useful for shifting the horizontal \"origin\" of the screen \t* Done: If the write pixel logic does the same kind of transparency test as the regular sprites (read, test, then optional write / re-write value) this would allow the highest priority sprites to be drawn first and avoid dropout issues better...    * Rotated Sprites2 \tdouble tempRot = Math.toRadians(33.0f); \tint rotpixelX = (int)(((double)pixelX * Math.cos(tempRot)) - ((double)pixelY * Math.sin(tempRot))); \tint rotpixelY = (int)(((double)pixelX * Math.sin(tempRot)) + ((double)pixelY * Math.cos(tempRot))); \tpixelX = rotpixelX; \tpixelY = rotpixelY; \tif (pixelX >= 0 && pixelX < 32 && pixelY >= 0 && pixelY < 32) {  \t// Rotation with origin correction                 int pixelX = (currentSpriteXPixel >> 5) & 0x1f;                 int pixelY = (currentSpriteYPixel >> 5) & 0x1f;                  pixelX = (currentSpriteXPixel >> 3) & 0x7f;                 pixelY = (currentSpriteYPixel >> 3) & 0x7f;                  double tempRot = Math.toRadians(display.getFrameNumberForSync());                  // Note, reverse the rotation for the origin                 pixelX += 64.0f * Math.cos(-tempRot) - 64.0f * Math.sin(-tempRot);                 pixelY += 64.0f * Math.sin(-tempRot) + 64.0f * Math.cos(-tempRot);                  pixelX -= 64.0f;                 pixelY -= 64.0f;                  int rotpixelX = (int)(((double)pixelX * Math.cos(tempRot)) - ((double)pixelY * Math.sin(tempRot)));                 int rotpixelY = (int)(((double)pixelX * Math.sin(tempRot)) + ((double)pixelY * Math.cos(tempRot)));                  pixelX = rotpixelX >> 2;                 pixelY = rotpixelY >> 2;                 if (pixelX >= 0 && pixelX < 32 && pixelY >= 0 && pixelY < 32) {                     pixelX &= 0x1f;                     pixelY &= 0x1f;  \t// Rotation with a sqrt(2) scale fix applied, to avoid sprite bounding edges                 int pixelX = (currentSpriteXPixel >> 5) & 0x1f;                 int pixelY = (currentSpriteYPixel >> 5) & 0x1f;                  pixelX = (currentSpriteXPixel >> 3) & 0x7f;                 pixelY = (currentSpriteYPixel >> 3) & 0x7f;                  double tempRot = Math.toRadians(display.getFrameNumberForSync() * (drawingSpriteIndex / 2));                 if ((drawingSpriteIndex & 1) == 1) {                     tempRot = Math.toRadians(-display.getFrameNumberForSync() / drawingSpriteIndex);                 }                  final double root2 = Math.sqrt(2.0f);                 // Note, reverse the rotation for the origin                 pixelX += (64.0f * Math.cos(-tempRot) - 64.0f * Math.sin(-tempRot)) / root2;                 pixelY += (64.0f * Math.sin(-tempRot) + 64.0f * Math.cos(-tempRot)) / root2;                  pixelX -= 64.0f;                 pixelY -= 64.0f;                  int rotpixelX = (int)((((double)pixelX * Math.cos(tempRot)) - ((double)pixelY * Math.sin(tempRot))) * root2);                 int rotpixelY = (int)((((double)pixelX * Math.sin(tempRot)) + ((double)pixelY * Math.cos(tempRot))) * root2);                  pixelX = rotpixelX >> 2;                 pixelY = rotpixelY >> 2;                 if (pixelX >= 0 && pixelX < 32 && pixelY >= 0 && pixelY < 32) {                     pixelX &= 0x1f;                     pixelY &= 0x1f;    * @TC-9 created for 32x32 behaviour    * @TC-1: When using \"enable APU mode\" and \"enable user port bus debug output\" the debug output needs to include valid \"wait for\" information so that it can be fully tested with the APU hardware \tThis \"wait for\" information should be the same as \"enable video display bus debug output\" and the APU hardware output should roughly match what is observed from \"enable video display bus debug output\" \tThe APU hardware output can then be used with the video rendering \t* This mostly works, however at the moment the data from data writes done in the feature file are not fully captured in the user port debug: VideoHardware\\target\\debugDataJustUserPort.txt \tData up to the first d$9e0001** with enable display bit $20 set will be captured in VideoHardware\\target\\debugData.txt \t\tThis is up to the first w$ or ^-$01 in that file \t* So copy the whole chunk from there to the start of debugDataJustUserPort.txt, replacing everything up to the first w$ or ^-$01 \t\tThen use debugDataJustUserPort.txt in the APU simulation \t* Then for the file BombJack\\output\\DebugAPUOutput.txt \t\tThe initial waits before  d$9e0001** with enable display bit $20 will need to be changed from \"w$\" to \";w$\" \t\tThen DebugAPUOutput.txt should be able to be used in the video simulation to check APU generated output \t* At the moment the video simulation with APU output seems to be roughly OK, but some of the waits seem to be missed? \t\tReplacing all \"w$ff03ff00\" with \"w$ff01ff00\" to ignore the _VIDCLK seems to make most (not all) frames better \t\tAlso making the DigitalData generator use a faster clock rate helps \t\t* This is most likely due to some waits appearing just before the last data write is completed     * @TC-11: Vector display layer \t8K for colour, 8K for scan length \tTwo banks of this for displayed and back buffer screen \tWill need a bank selection register \tLow vsync resets the pixel count, pixel, address \tLow display enable behaves like vsync \tEach new line reads the colour and scan length pair in parallel, the pixel clock counts down for the scan length byte before reading a new pixel/length pair. \tEnd of line -ve _hsync edge increments the read address \tOr if the inverted length (read into the counter) increments when it reaches zero will trigger a read address increment \t\tAnd new length read \t\tAnd pixel colour latch \tThis gives a maximum theoretical scan complexity of 36 segments per scan, assuming 224 scans \tThe existing C64 VectorBitmap demo that calculates scans could be used for this    * Vector layer: Storing palette/length pairs needs to be in sequence $0000-$3fff or $8000-$bfff, but stored in the RAMs alternately to allow the parallel read     * @TC-11-000433.bmp \t3D rendering almost works, but there seems to be some weird scan corruptions \tAlso seeing: com.loomcom.symon.exceptions.MemoryAccessException: uninitialised memory read: 2D75  F5 19     SBC $19,X      [$00]@$0033 A:39 X:1A Y:19 F:25 S:1F3 [..-..I.C]    SBC Poly2D_vertexBufferX \tPoly2D_loadVertsIntoRegs: sbc Poly2D_vertexBufferX, x \tx should b 0-3 at this point \t** Will need to enable: I enable trace with indent     * Add automatic guard memory ranges that assert when read / write / execute operations happens \tThese can be read from label pairs that add buffer memory space \tA macro can be used, the same label names sorted by their memory addresses represent the address pairs \tSyntax to submit label/address pairs     * APU Source debugging works, however the APU instructions are all implemented as macros, so the macro source is shown. Doh. :) \tACME will need to be improved to output the debug source hierarchy in the PDB, i.e. which file include which file \tOr ACME parses APU code directly without macros \tThen AddrInfo can be updated to include the source file levels after the primary level... \t** Or have the option of reporting the parent in the PDB after encountering a ! pseudo op. The PO would basically say \"output the level above this macro\" for the lifetime of the macro \t!previouscontext added to ACME    * Fix sprites2 alignment (shift 2 pixels to the right) in emulation to match simulation and reduce calculation by 2 extra clocks    * Add sprites2 clock speed selection in emulation    * For if (pixelsSinceLastDebugWrite >= pixelsSinceLastDebugWriteMax) \tThis test is actually bugged as it outputs something like: \t\tw$ff03ff00,$72004800 \t\td$980f01f8 \t\td$9e0a010f \tThis does not reflect accurately the position to actually wait for when writing... \tNeed to debug \"APU_ProcessSpriteStrip\" and double check the enable is done 16 pixels after the sprite register updates... \tThe the simulation can be fixed if needed. But data indicates that actually it should be OK.    * Layer combiner for pixel output: com.bdd6502.DisplayBombJack.addLayer \tAdd a pixel combiner for two inputs to one combined output. This will be useful for the SF2 demo which uses two sprites planes \tCopy from @TC-8 \tHardware wise the layer enable signal from the pixel header would need to be split to the two input pixel headers    * InitWindow uses the correct window size to reflect the screen display aspect ratio    * Sprites2: Add debugger output to show the used scan time for each line of calculated sprites2 \t* Best place to add that is: debuggerUpdateRegs \t^^ Done    * Removed voicesLoopMask since the Audio 9.3 hardware assumes loops are always enabled now    * Updated non-looped samples to always use the first exported sample 0x80 byte    * Syntax to randomly initialise data in all connected devices and memory \tGiven randomly initialise all memory using seed 4321    * Added Audio layer debug in the register view, if it's enabled    * APU disassembly seems to ignore locations 0-$10 during the SotB demo? \t(Previous fix)    * Break on address \tDone - CPU: receivedBreakAt \tDone - Add \"delete\"/\"del\" command to remove address breakpoints    * BDD6502 needs to output compatible break response... \tAlso \"break\" might need to show a list with index values like Vice... \t\"delete\" also \tbreak 300 \t\tBREAK: 2  C:$0300  (Stop on exec)     * Add cartridge support \tRead CRT files and store their banks and addresses into a map for easy lookup \tAdd syntax to optionally configure cartridge bank address, whether it is read enabled \tAdd syntax to specify combinatorial logic (use the variable resolution code ) on multiple locations and enable/disable carts banks, kernal/BASIC ROMs etc \t\tThis can also support bank sizes by mapping cart banks with addresses \tObviously more than one rule and multiple ROM binary or CRT files can be specified allowing complex cart bank/ROM arrangements to be created \t\tEF3 and GMod2 need support \t\t\tcom.loomcom.symon.Bus.write processorPort theProcessorPort \t\t\t\tDetect theProcessorPort changes \t\t\t\t\tfeatures/C64ROMs.feature \t\t\t\t\tGiven a CRT from file \"some\\file\" \t\t\t\t\t\tWill implicitly enable processor port. Note: IO Write detected: \t\t\t\t\t\t\tDone: theProcessorPort needs $17 on reset to emulate the C64 \t\t\t\t\t\tNote: C:\\work\\c64\\stdlib\\stdlib.a lines 19-35 \t\t\t\t\t\tDone: However the precise CRT support will need early hooks into Bus read and write \t\t\t\t\t\t\tBut must only access the cart when ProcessorPortDefault or ProcessorPortCharROMBASICKERNAL \t\t\t\t\t\t\tOr for EF3 EASYFLASH_CONTROL_ULTIMAX mode (the default) where the kernal is mapped from the cart \t\t\t\t\t\t\t\tEASYFLASH_CONTROL_8K is used very early if most of my startup code \t\t\t\t\t\t\t\t>> Just assume EASYFLASH_CONTROL_8K? \t\t\t\t\t\tThen the scenario can start the CPU at the intended vector address \t\t\t\t\tNote these will be needed in the scenario, but don't need code updates: \t\t\t\t\t\tGiven a ROM from file \"..\\..\\VICE\\C64\\kernal\" at $e000 \t\t\t\t\t\tGiven a ROM from file \"..\\..\\VICE\\C64\\basic\" at $a000 \t\t\t\t\t\tGiven add C64 hardware \t\t\t\t\t\t\tAdds devices to cover $d000 - $dfff \t\t\t\t\tDone: Will need expansion to match the processor port config \t\t\t\t\t\t>> com.loomcom.symon.Bus.buildDeviceAddressArray can have an array of deviceAddressArrayWrite and deviceAddressArrayRead indexed by the lower three bits of the processor port \t\t\t\t\t\t\tBus read and write will need different behaviour as writes go to the underlying RAM \t\t\t\t\t\t\t\tfile:///C:/work/C64Docs/unusedino.de/ec64/technical/aay/c64/memcfg.htm \t\t\t\t\t\t\tAnd will automatically map in devices with $a000 $d000 $d800 $e000 addresses \t\t\t\t\t* Need to test bank switching behaviour. Create a function that stores known data when it's called from ROM.    * To aid debugging hardware, displaying the pixel palette index and RGB colour under the mouse cursor hovering over the screen would be very useful \tAlso which layer it came from \tCan be optional syntax since it will probably have a performance impact \tSet the title with details? \tcom.bdd6502.DisplayBombJack.calculatePixel will need to store extra details \tJust before some calls to com.bdd6502.QuickDrawPanel.fastSetRGB \tcom.bdd6502.DisplayBombJack.RepaintWindow to do the update     * APU: Hardware test seems to show the APU will run its code and even the multiplex sprites and raster bars will work \tBut not in the CPU sending data to the APU (or externally?) interrupts APU processing \tThe more data sent to the APU the higher the chance the APU will hang \tThis indicates the bus arbitration is not functioning properly \t\t>> Not entirely a surprise since the memory timing could have short pulses etc. These short pulses happen because the internal bus cut-off (going into RAM U17 APU data) and switch over can happen at any point \t** This needs more testing with some simpler example code. Perhaps some raster bars and the CPU not sending any new memory updates either to the APU or the external bus... \t* If no workaround can be found, perhaps an alternative design for the bus arbitration \t\t>> Workaround was found (see this commit APUAvoidRasters and APUAvoidRastersTable) however it is slow, so not suitable \t\tFor the internal bus writes (from the CPU) rely on the fact that they are relatively slow and store the last 24 bit address and data into temporary latches \t\t>> Done: Instruction and data selection (writes) no longer reset (retry) the APU instruction \t\t\tThe temporary latch writes can use the _IMEWR (IEMEMWRITE) \t\t\tThe register storage for _RESET and ENABLEAPU must still use original IEBS IEA IED and _IMEWR \t\t\tThe internal RAMs the BUSCHOICE must now use the external EBBS EA ED and _MEWR \t\t\t\tThis would theoretically mean the APU self write its internal memory using external writes, which is OK, but not ideal. Still use the internal write flag. \t\t\tUsing a new 1-of-4 to output to EBS EA ED and _MEWR _MERE (as before): \t\t\t** When the APU is RESET/disabled then existing write timings from the userport interface are used \t\t\t** Only when the APU is active are new write timings used \t\t\t\tIf _RAMSWITCHTOPASSTHROUGH = 0 then use the original IEBS IEA IED IEMEMWRITE IEMEMREAD \t\t\t\tIf _RAMSWITCHTOPASSTHROUGH = 1 and InterceptBus = 1 then use RINT IDATA _ExternalMEWRPulse \t\t\t\tIf _RAMSWITCHTOPASSTHROUGH = 1 and InterceptBus = 0 then use latched values logic: \t\t\t\t\tUSECACHE and the eventual new generated write pulse are created from a counter and demuxers (like the API instruction) \t\t\t\t\tIf the latched EBBS (TLIEBS) is not 0 (indicating something is needed) \t\t\t\t\t\tAt the start of the APU instruction then: \t\t\t\t\t\t\tPause the instruction (not retry it) when trying to increment the PC and the current instruction is not trying to do any internal or external writes (which prioritises APU writes): \t\t\t\t\t\t\t\tPCINCR = 0 \t\t\t\t\t\t\t\tand not InternalMEWR \t\t\t\t\t\t\t\tand not InterceptBus \t\t\t\t\t\t\tExecute the latched write by using the new 1-of-4 paths: Create a USECACHE and new write pulse (per above note for USECACHE) \t\t\t\t\t\t\t\t>> Update NoLatchedWrite on +ve PCINCR \t\t\t\t\t\t\t>> Needs _LATCHEDWRITEPulse \t\t\t\t\t\t\tClear the latched data (end of the generated write cycle) using a new input into _FLUSHCACHE, which allows the APU to continue instructions \t\t\t\t\t\tThis is a fully delayed and cooperative internal/external bus write model instead \t\t\t\t\t\t\t>> This would actually remove the need for any instruction retries. \t\t* Debugging notes \t\t\tDuring reset and disabled period, instruction and data writes work \t\t\t** Latched writes \"b$11,b$12,b$13,b$14,b$15,b$16,b$17\" are unreliable \t\t\t\tWhen writing $4102 $13 \t\t\t\tOh bother, it's because the APU instruction is waiting for a HV position \t\t\t\tStill unreliable, but $4100 $11 didn't write \t\t\t\tBreak on LatchedWriteDesired \t\t\t\t\tDebug data clock reverted back to 1M \t\t\t\t\t>> There needs to be some logic that reads LatchedWriteProceed if it's waiting \t\t\t\t\t\tInstrIsWaiting = 1 when instruction is waiting \t\t\t\t\t$4100 $11 didn't write because its write happens while the previous cached write is being written \t\t\t\t\t\tPCINCR = 0.8 MHZ so data clock back to 500KHz \t\tDone: Remember to enable tree movement and remove the APUAvoidRastersTable code... \t\t\t; For MAPUAvoidRastersTest: Define out the next line to simply remove the avoid rasters code \t\t\t; For MAPUAvoidRastersTest: Comment out the next line to simply remove the table creation \t\t\t; For MAPUAvoidRastersTest: Comment out the next line to simply remove the test \t\t* Done: Check the _MEWR timings and address setup timings are balanced, for (all in ns): \t\t\t\t\t\t\t\t\t\t\t\tSame write period\t\tBus\t\t\tWrite time\t\tPre\t\t\tPost \t\t\tA5 _RAMSWITCHTOPASSTHROUGH = 0\t\t2000 (500KHz)\t\t\t395\t\t\t120\t\t\t\t155\t\t\t120 \t\t\tA3 InterceptBus = 1\t\t\t\t\t1650\t\t\t\t\t580\t\t\t182\t\t\t\t202\t\t\t195 \t\t\tA4 LatchedWriteActive = 1\t\t\t2230\t\t\t\t\t512\t\t\t160\t\t\t\t225\t\t\t132\t(not centred) \t\tDone: \t\t* Need to reconcile data and images for @Demo6 output with emulation and simulated APU \t\t\tSee: \"* For APU validation when running @Demo6:\" \t\t* Update emulation: When InstrIsWaiting check (debug break/error) that there are no InternalMEWR InterceptBus operations in the previous or current instruction \t\t\tAlso any userport writes must now be delayed, to emulate the latched memory write behaviour including delays for any InternalMEWR/InterceptBus and no delays while HV wait \t\t\tAlso there are a couple of extra cycles if the APU has to pause while a latched write happens \t\t* Final feature file validation \t\t* Replace 6116SA20TPGI with https://www.mouser.sg/ProductDetail/Renesas-Electronics/6116LA20TPG?qs=SmUuHNCnblrwZH5u1F5zAw%3D%3D \t\t* Layout group and packages \t\t* Check for merged devices \t\t* The emulation data output debugData.txt works. There are no reconciliation errors with simulated APU. \t\t\t\tBut using the APU simulated output DebugAPUOutput.txt generates some problematic video issues and some memory writes seem to be wrong. \t\t\t\t\tThis looks like a timing issue to do with the simulated APU output using more frequent waits? \t\t\t\t\t>> Part of the problem was the next HV wait being too soon, so the data gen was missing the event. \t\t\t\t\t\tThis was most obvious by the screen not rendering raster bar effects for part of the display period \t\t\t\t\t\tThis was fixed in the data generator where if the next wait event happens during a write it will be processed \t\t\t\t\tSome update issues remain with the APU simulated data, but not from the emulated output. Most likely also timing based. \t\t\t\t\t\t>> Check the Sprites2 writes, since their first frame is not correct \t\t\t\t\t\t\tRecon is fine... \t\t\t\t\t\t\tTry disabling the waits for Sprites2 memory and visually check \t\t\t\t\t\t\tWTF!! C:\\work\\c64\\VideoHardware\\target\\debugData - Copy.txt has: \t\t\t\t\t\t\t\td$9200010b \t\t\t\t\t\t\t\td$920101b4 \t\t\t\t\t\t\t\td$92020114 \t\t\t\t\t\t\t\td$92030158 \t\t\t\t\t\t\t\td$92040120 \t\t\t\t\t\t\t\td$92050133 \t\t\t\t\t\t\tThis is expected. But \"C:\\work\\BombJack\\output\\DebugAPUOutput - Copy.txt\" has: \t\t\t\t\t\t\t\td$9200010b \t\t\t\t\t\t\t\t;@time:0.032650 \t\t\t\t\t\t\t\t;delta:0.000002 \t\t\t\t\t\t\t\t;w$ff03ff00,$f2005d00 \t\t\t\t\t\t\t\td$920101b4 \t\t\t\t\t\t\t\t;@time:0.032652 \t\t\t\t\t\t\t\t;delta:0.000002 \t\t\t\t\t\t\t\t;w$ff03ff00,$f2006900 \t\t\t\t\t\t\t\td$92020114 \t\t\t\t\t\t\t\t;@time:0.032656 \t\t\t\t\t\t\t\t;delta:0.000004 \t\t\t\t\t\t\t\t;w$ff03ff00,$f2028200 \t\t\t\t\t\t\t\td$92040120 \t\t\t\t\t\t\t\t;@time:0.032658 \t\t\t\t\t\t\t\t;delta:0.000002 \t\t\t\t\t\t\t\t;w$ff03ff00,$f2028e00 \t\t\t\t\t\t\t\td$92050133 \t\t\t\t\t\t\tThe write d$92030158 is completely missing?!!! \t\t\t\t\t\t\tEven worse the recon isn't showing any differences!!! \t\t\t\t\t\t\t\tpython C:\\Work\\BombJack\\ReconcileData\\ReconcileData.py \"C:\\work\\c64\\VideoHardware\\target\\debugData - Copy.txt\" \"C:\\work\\BombJack\\output\\DebugAPUOutput - Copy.txt\" \t\t\t\t\t\t\t\tWTFx2 BombJack\\ReconcileData\\ReconcileData.py has a bug where it wasn't filtering out audio writes properly \t\t\t\t\t\t\t\t\toh FFS \t\t\t\t\t\t\t\tThe missing write d$92030158 is present in \"C:\\work\\c64\\VideoHardware\\target\\debugDataJustUserPort.txt\" \t\t\t\t\t\t\t\tSo the new APU must be missing it... \t\t\t\t\t\t\t\tNeed a breakpoint on attempting to write that value... \t\t\t\t\t\t\t\tFound the issue, the positive edge on USECLK meant that sometimes USECACHE was very short and basically skipped \t\t\t\t\t\t\t\t\tThis meant the value was not cached and caused missing writes \t\t\t\t\t\t\t\t\tCapture for output\\DebugAPUOutput.txt has \"ignore zero writes\" enabled, which made it harder to spot \t\t\t\t\t\t\t\t\tAdding an extra USECLK input for the latch set worked. This gives adequate time from the negative edge to the next positive edge to signal USECACHE \t\t\t\t\t\t\t\t>> Data recon and image recon passed \t\t\t\t\t\t\t>> Debug image 7 is wrong when using emulation output, but correct when using simulated APU output.\t \t\t\t\t\t\t\t\tAPU simulated output image animation looks OK. \t\tTODO: \t\t\tTest place and route \t\t\t\tNeeded a bigger layout \t\t\t\t8 layers, more compact: V9.4\\APU - Routed - Tightly 2.pdsprj \t\t\t\t\tImported: Eight layers.LTF \t\t\t\t\t\tNeeded some planes created, layer pairs, and design rules signals to layers.    * When there is a screen refresh any picked pixel information is refreshed    * Enable/disable pixel picking with 'P' on the keyboard    * Hmm I wonder if I can profile 6502 code by counting cycles for every jsr until its corresponding rts... \tSome monitor commands to: \t\tprofile start \t\tprofile stop \t\tprofile print \t\tprofile reset \t* I will want to note the interrupt status when doing the jsr and only count cycles while it maintains the same status. \t\t* And handle rti and obviously the kernal vectors \t* This method provides a live view, partially through a subroutine. It is expensive: \t\t* Whenever a jsr is encountered add it to a map. \t\t* Each cycle accumulates the count in all listed jsr, with the correct status flag. \t\t* When it has a corresponding rts, remove the map entry while noting the accumulated cycle count. Add the total for that jsr to the jsr's address map. \t* This method has less performance impact: \t\t* Whenever a jsr is encountered add it to a map with the current cycle count. \t\t* When it has a corresponding rts, remove the map entry while noting the cycle count delta. Add the total for that jsr to the jsr's address map. \t* When printing: \t\tPrint the address, label, total cycles    * Add syntax to start/stop/print/test profiled code     Given profile start     Given profile clear     Given profile stop     Given profile print     Then property \"test.BDD6502.lastProfile\" must contain string \" : Video_WaitVBlank : \"    * Add APU write wait indicator in debug \t<<Wait RAM>> will be seen in the APU debug output if the external (user port or APU) memory write causes data to pass through or to the APU     * Emulation to hardware difference \tUsing the below in Demo6, the left and right border are the same \t\tjsr Video_SetAddressVideoOverscanExtentRegisters     \tlda #kBus24Bit_VideoLayer_OverscanExtent_Default     \tsta CIA2PortBRS232     >> But using kBus24Bit_VideoLayer_OverscanExtent_Wide the left border on hardware seems to be missing one pixel, this might be the TV     \tkBus24Bit_VideoLayer_OverscanExtent_Wide\t\t= $39     \tUsing $49 the hardware is the same as the emulation, so ignore this, it is probably the TV or the conversion box...     \t\tThe video conversion box test card actually outputs a slightly wider signal than the large TV displays. The smaller display shows this     \tUsing the smaller display kBus24Bit_VideoLayer_OverscanExtent_Wide is the same as the emulation, so the large TV is trimming the display     \tUsing $29, which is too far left, does not show any extra picture on the large TV     \t\tThe smaller display actualy shows an extra 4 pixels compared to the TV, but still not exactly the same as the emulation     \tUsing $2a the smaller display actually shows ~4 pixels more to the left and right edge     \t\tCreated kBus24Bit_VideoLayer_OverscanExtent_UnsafeWide\t= $2a for this     \t\tThis matches precisely the video conversion box output border extent     * Make sure the default window size has rendered pixels that are square, so the regular dithering is consistent \tThis can be forced over the whole screen area by adding a suitable output pixel xor value to the merge control register \t\tjsr Video_SetAddressMergeLayer \t\t+MBus24Bit_Send8BitValue kBus24Bit_MergeLayer_Register_Control_Dither \t\t+MBus24Bit_Send8BitValue $0f \tAdded a better scale (2x) in com.bdd6502.DisplayBombJack.InitWindow()    * The rendered video hardware output needs to be moved up 8 pixels to match with the simulation output and also the APU raster values in @Demo6 sky colour changes (for the above line)     * Added \"--compressData <input filename> <output filename>\" as a general compression option.     * Dither in emulation should match the hardware... \tIt does now    * Exact address matching emulation \tAnd the display uses exact address matching \tAnd the audio expansion uses exact address matching \tAnd the APU uses exact address matching \tAnd the layer uses exact address matching     * When trying to debug failing code, it would be useful to had syntax to read expected memory for comparison to be used for stores into memory. \tThen break on the first instance of a store not matching the expected memory. \tThis would allow the CPU history to be inspected etc. \tNew syntax: \t\tThen for memory from \"$500\" to \"$510\" expect a write to \"$500\" with value \"$a2\" \t\tGiven load binary file \"test.prg\" into temporary memory \t\tAnd trim \"2\" bytes from the start of temporary memory \t\tThen for memory from \"$500\" to \"$510\" expect writes at \"$500\" with temporary memory     * Save C64 memory range with optional 2 byte header     When save 6502 memory with two byte header from \"$410\" to \"$418\" to file \"target/mem2.bin\"     When save 6502 memory without two byte header from \"$410\" to \"$418\" to file \"target/mem2.bin\"     Then assert that file \"target/mem1.bin\" is binary equal to file \"target/mem2.bin\"","shortMessageHtmlLink":"; Done items Added: Given I am using C64 processor port options This …"}},{"before":"6511b5885153d8c7b72ba9388ff7ee1956f6509c","after":"b6508def12bb7e83c68162d44b2951fb4b5d09e1","ref":"refs/heads/master","pushedAt":"2023-09-20T04:19:44.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"martinpiper","name":"Martin Piper","path":"/martinpiper","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2396609?s=80&v=4"},"commit":{"message":"Update TODO.txt","shortMessageHtmlLink":"Update TODO.txt"}},{"before":"26e34a1acb2fbaa8a0554a75956121bc9159d8e4","after":"6511b5885153d8c7b72ba9388ff7ee1956f6509c","ref":"refs/heads/master","pushedAt":"2023-09-16T08:29:53.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"martinpiper","name":"Martin Piper","path":"/martinpiper","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2396609?s=80&v=4"},"commit":{"message":"Report proper errors if there is any issue during macro parsing","shortMessageHtmlLink":"Report proper errors if there is any issue during macro parsing"}},{"before":"76df9f32e6903b7721077a75a4735c7178e9ed09","after":"26e34a1acb2fbaa8a0554a75956121bc9159d8e4","ref":"refs/heads/master","pushedAt":"2023-09-16T07:50:29.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"martinpiper","name":"Martin Piper","path":"/martinpiper","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2396609?s=80&v=4"},"commit":{"message":"Adding expected memory write syntax for enhanced debugging","shortMessageHtmlLink":"Adding expected memory write syntax for enhanced debugging"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAET_wd_wA","startCursor":null,"endCursor":null}},"title":"Activity · martinpiper/BDD6502"}