Macintosh-Tools/moa
1
0
Fork 0
mirror of https://github.com/transistorfet/moa.git synced 2024-11-28 20:50:13 +00:00
Code Issues Projects Releases Wiki Activity

Added dev logs

Browse Source
This commit is contained in:
transistor 2021-12-23 19:32:48 -08:00
parent 825331df39
commit 4c99cbf240
1 changed files with 276 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

276
docs/log.txt Normal file
View File

@ -0,0 +1,276 @@
- 2021-09-28: started the project, computie monitor working after a week
- 2021-10-08: I think the Computie OS could boot by this point
- 2021-10-14: I think I started working on the genesis at this point, or maybe a bit before
- 2021-10-20: added frontend refactoring
- 2021-10-25: added Sega Genesis peripherals for the first time, even though I think I had been
working on it for at least a couple weeks by that point
- 2021-10-27: added minifb frontend
- 2021-11-01 to 2021-11-11: worked on the Z80/TRS-80
- 2021-11-13: was working on Mac (and Genesis a bit)
- 2021-11-28: took up the Genesis again after posting first article
Genesis
=======
(pieced together after the fact)
before 2021-10-25
- controllers and coproc controls aren't an issue as dummies until much later
- implement dma
- try implementing the scrolls and get nothing
- try printing just the patterns and get nothing
- cram is 0s, fight and find a few dma/transfer bugs
- cram is then sorta working, getting 0xeee and 0xee0 colours, but showing as pink
- turns out to be index issue into cram, fixing makes colours ok, but still nothing on screen
2021-10-25
- still nothing on the screen.
- maybe it's not working because I haven't implemented the h/v blanking bits at all, so I add
them and it makes something appear instead of blackness. At least for Sonic 2, it waits
for the vblank bit to be set
2021-10-26
- what caused those pink screens I was initialling getting?!? there was an issue with the cram
not being correct, and I remember fighting a ton with that...
- it was caused by the cram being byte-wise, but the index into the array when fetching the
colour was not multiplied by 2, so the colours were wrong. It was fixed in commit 109ae4d
- add the BusPort thing to fix issues with how data is written. Some writes can bet 4 bytes, or
2 bytes, and they could be to the same address or the adjacent address, so adding BusPort,
which breaks up the reads into all 2 bytes reads as the real hardware would see simplifies
the number of cases to deal with when accepting data on the VDP ports
2021-10-27
- oct. 27, commit 109ae4d doesn't seem to work and it seems to be related to the interrupts not,
which I got working in the immediately following commit. It actually does work but is super
slow to display anything, which was fixed later, as in minutes before the screen goes white
to display the sega logo. The interrupt print log is very slow, only a few interrupts in a
minute
2021-10-29
- the next commit 250c0 speeds things up by making the step function occur less often for the vdp
Also this commit adds code to change the interrupt mask, but only if a hardware interrupt occurs
I think this was causing problems with the computie binaries. There's still an int bug
- commit 93c080e: finally fix interrupts properly. The code I was using before didn't properly
reset the interrupt signal, so it couldn't reoccur. The CPU now checks the interrupt controller
each cycle for a pending interrupt, rather than relying on a callback and the Interruptable trait
which I partially removed.
- it now actually runs and shows the screens at a reasonable speed
- I recall there was an issue with the pattern indexing using the wrong formula to calculate, and
that caused some of the issues
-----
2021-10-31
- at this point I had finally gotten the scrolls to work enough to print the SEGA logo at the start
2021-11-01
- started working on the Z80 and TRS-80 implementations, as well as debugging the Mac stuff, which
I think I was doing for most of November (instead of working on the Genesis impl)
2021-11-30
- after getting things working somewhat with the scrolls, but not the sprites, I finally found
ComradeOj's demo, which I'm now using to test with, and I've also got BlastEm setup so that I
can compile the code and modify it to print out all of vram so that I can verify against mine
- there is a difference in VRAM in the patterns section with non-zero data starting at VRAM:0020
the first differing byte is VRAM:0046 which is 0x1111 in my VDP but 0x0000 in blastem's VDP
- checked what data was actually being transferred to VRAM, the source data is in ram at 0xff2000
(ie. 0xff2000 is copied to VRAM:0020 for some number of bytes, maybe 256 or so)
- ram copy of data is incorrect so the problem is not the VDP code specifically, but the code
that loads the ram.
- traced it further to the decompress function called at 0x00c0, this function definitely loads
the source ram and it's definitely incorrect long before the actual VRAM is loaded
- so I set a breakpoint at c0 in blastem, and then at that point set 266 and continued until the
first different byte was loaded, and inspected all the CPU registers at that point. The only
one differing is %d6 which holds a copy of the flags, which is somehow/somewhere restored after
being saved. It's 0x2700 in blastem but 0x2710 in moa...
- so far I'm suspecting that the Extend flag is not being correctly simulated somewhere, and
that's causing problems. The code uses roxd instructions which use the Extend flag... sus
- the two places where %d6 is set in the decompress function are just after LSR instructions.
I didn't have tests for LSR or LSL, so adding some caught the issue where Extend is not cleared
by the instruction nor by the logic flags code (since most logic instructions don't affect extend)
- fixing this made the text of the demo appear correctly, along with colour changing of the text,
but the background is not rendering at all
- switching gears now, trying GenTestV3. A write to read only memory occurs at 0x2976 because %a4
is 0 when it should be the VDP data register (0xC00000)
- tracing back, there is some code run at 0x2572 which causes the registers to be cleared, but
checking in BlastEm's debugger with a breakpoint there shows it's not executing there, so this
is a problem in moa and it's caused an erroneous processor state...
- there's a comparison at 0x255e which jumps to the code that shouldn't run, checking in BlastEm
shows that the previous comparison should not be equal (flags are 0x2700), but in moa it's 0x2704
- the comparison is correct, but the value in %d7/%d3 should be 0xff instead of 0xef
- at 0x2a78 the values are read from the controller inputs 0xa10003, and this is what's not correct
the data read is 0 but should be something else I think (start of code is 0x2a4a)
- it appears that the controller inputs should be 1s instead of 0s when not pressed?? or when all
bits are 0?
- changing to that behaviour makes it work until the ram test is invoked, but it seems that BlastEm
also does write to address 0 when the RAM test is run...
- the writing to address 0 might be an unintentional bug in the rom, which doesn't otherwise affect
anything because removing read_only makes it work enough to run
- next issue is controllers, it turns out the button logic is inverted, so the rom expects to read
all 1s (0xfff) for the button states, and a bit will drop to 0 when it's pressed.
- now there's an issue with the 'a' button to go to the info screen where it sometimes seems to run
the memory test instead, or otherwise behave inconsistently, and it's probably that 1.5ms delay
that resets the cycle to avoid the extra 3 buttons. This rom probably only reads the first 3 and
expects the counter to reset
- turned out that i actually need to reset the th counter after the ctrl port is written to, and the
count/next_byte logic was broken, so the buttons were incorrectly mapped
- now the test works, memory tests work, and so far looking at the info pages, the sprites are almost
correct, but sonic is busted. It might be something to do with the sprite being reversed
2021-12-04
- colour bleed test: 0x230a
- there are two of the four bars of colours with the rest black except some garbage at the bottom.
- I was able to modify the pattern printing to put a white dot in the upper corner so I could count
the cells to figure out where in memory the garbage pixels were appearing. The garbage starts on
a ways into line 23 and continues on lines 24/25/26, where the scroll is 64 cells across, and the
start of scroll a is 0xE000, which makes 0xEB80 about the start of the garbled line.
- the cells in the table look correct here, each line contains increasing pattern numbers (0x0518 at
the garbled cells), so the problem isn't here
- looking at the pattern for 0x518, which corresponds to address 0xA300 in video memory, the data is
not at all like the regular patterns at the start of VRAM. Comparing it to blastem shows the VRAM
is correctly regular (0x1111 or 0x5151 and other regular repeating patterns), so it looks like
a problem with loading VRAM
- look at the included source, the start of the colour bleed test is 0x2056, the DMA transfer is set
up at 0x207a which then writes to the control port to start the transfer
- I started suspecting the transfer count might be the number of read/write cycles as opposed to the
number of bytes, and only half the data is transferred, which would explain why the bottom half of
all the screens was broken but the top half looked fine
- sure enough, checking in blastem it even prints $4600 words, but moa was subtracting 2 from the
count. Changing to 1 pretty much fix all the remaining glitches, and sonic 2 now displays pretty
well
- started implementing scrolling. It seems the horizontal and vertical values work opposite to each
other. The horizontal value needs to be subtracted. I might also need to convert them to signed?
- initial problem was caused by getting the mask wrong (0x3F instead of 0x3FF), but the mask is
required because technically games can use the extra bits for whatever they want =(
- the background was still glitching and it turned out to be because for scroll b, I was reading
the scrolling data 1 byte over instead of 2 bytes over (because they are words). That fixed
the glitching
2021-12-15
- started trying to make horizontal line scrolling work. Turns out to not be too hard except that
there's a few glitches
- one turned out to just be that i was multiplying by 2 instead of 4 for the hscroll addr
- the other is that it's drawing the lines for scroll a and scroll b at the same time, and they
overlap incorrectly when the per-pixel column offset is different between the layers
2021-12-20
- looking into the hscroll and vscroll issue, I realized I wasn't adding the (vscroll % 8) value to the
pixel offset, which is now being added, which causes some glitches at the bottom/left of the screen,
but it now scrolls more smoothly in the vertical
- there is still an issue with the hscroll, particularly when the offsets are very different, no idea
- after spending the day looking into the slowdown issue, I found the issue. I started by looking at
the sonic 2 disassembly looking for code that reads the controllers (ReadJoypads) and then looking
for where that is called from, and found the Vint_Level function which after setting some breakpoints
is definitely only called during gameplay but is called each frame and reads the input before updating
the screen.
- looking at the code, and tracing the first few instructions where the ReadJoypads function is called
showed that it sometimes skipped over the various timer checks every other time it's called
- I added the system clock time to the debug output, which showed that it was indeed ~33_200_000 ns
between each call to Vint_Level
- so I turned on a debug message for the hardware interrupts and it showed the interrupt occurring
twice for every time the Vint_Level function is called. After the first vint, it takes ~14ms until
the Vint_Level function runs... looking at what runs by tracing that period between the int and call
shows that it's looping while checking the status bit of the VDP, which corresponds to the vblank
bit, of which there is a bad implementation that just turns the bit on after 14ms ... so it is
definitely a problem with the vertical interrupt and vertical blanking bit timing in the VDP step
- I had hackishly made some code to turn the blanking bit on at ~14ms, and then turn it off just before
the vint was triggered. It would have worked had the frame been drawn at the 14ms mark, and then the
blanking bit reset at 16.6ms. I've now changed it to be proper, in that the blanking bit is set at
15ms, the count is reset at 16.6ms, and the blank bit is cleared at 1.2ms
---------------------------------------------------------------------------------------------------
Macintosh
=========
- ram self test is run by jumping to 0x400694, which returns by jumping to %a6 which contains 0x4000f0
if it returns with eq set, it will jump to the system initialization at 0x40026c
it doesn't have eq set, so it ends up in an infinite loop.
- turns out MOVEM was broken such that it was incrementing instead of decrementing address (found by
inspecting the first byte of memory when trying to get 0x5555AAAA to cancel itself out
2021-11-19
- still not working, calling 0x4000f0 to fail. Turns out this is where the dead mac is supposed to
be printed, but it's not (found that from another blog post)
2021-11-23
- finally got dead mac screen showing with 0F0003 as the error. It wasn't showing because the 0 colour
used by the genesis, which is a mask colour, causes nothing to appear
- then the issue was the indexing of the memory page (x * 2) * y instead of (x * 2) + (y * 512/8)
- so the 0F0003 dead mac was caused by the first trap instruction in the ROM, appearing at 4002adc
It causes an illegal instruction, which then jumps to the exception entry points start at 4001aa
in rom which all jump to the same function at 4001d2, which then ends up in the failure
- trying to find why, i traced the program to find where the trap table was being set up, which
turned out to be around 400448 which is where I'd been debugging the last issue. It sets location
0x28 to 401018 which is the trap handler...
- 0x28 is not the illegal instruction handler, it's the 1010 line emulator exception... 1010 as it A
as in the A line traps... So the m68k is specifically not handling the a000 instructions correctly
- it's now getting past the dead mac, but instead it causes two writes to read only memory when it
tries to set some bits indirectly to an address in rom (0x4034ae), which is something do with the
drivers. The Sound and Disk drivers are opened and it's during each of the open functions that the
write occurs
- it's possible to continue (which might be in broken state) and it then attempts to write to
sequential addresses in upper ram which eventually spills over into 0x100000 which isn't mapped...
No idea if this is just because of something going wrong earlier, or if this is also an emulator bug
- the writes to rom issues happens during InitIO (0x400614), when initializing the first two drivers,
the Sound and Disk (I think). There is a pointer to a pointer to a value that contains 0x4034ae,
which seems to be calculated from a jump table, presumably pointing to something in rom that contains
the driver, but for some reason the code is bit setting that value. I'm not sure if the data is wrong
and it should normally see a 0 instead of the rom addr, or if there's a branch that shouldn't/should
happen that leads it to that code when it shouldn't
- c4c and c7c seem to be driver descriptors of some kind, each with a rom addr and what seems to be some
flags after that. They also have 0xfffb and 0xfffc. That said, if there's a bug in the code that
creates that data, it would likely be broken for both