SpritesMind.Net

I'm surprised you optimized my BCD routine without doing the look-up stuff on that one even though I mentioned that =P the idea being processing multiple bits together (which is precisely where I slacked off... I need to get that sorted out some day). Converting from 0 to 63 requires only one BCD b...

Here is my contribution to this topic: I am presenting 3 routines to do packed BCD conversion of a 32-bit unsigned integer. They pick up the number at d7 and store the packed BCD representation at the buffer at a6. Why doing integer to packed BCD? Well, because (1) this is the slow part on all code ...

Here is the test ROM source.

Yes, I know, AS and all. It works.

Yes. For me, who is not familiar with transistor stuff is not easy to figure out what it is: http://i.imgur.com/oXe6EJ7.png I had to google "transistor notation schema", to find something close, but closest what I've found is here: https://en.wikichip.org/wiki/cmos This picture: https://en.wikichip...

I do not understand, hasn't anyone looked at the CPU die shots yet? Basic die shots. Then, Quietust has made a great contribution by isolating the metal traces . Olivier Galibert was able to make use of this layer image, with a few corrections, to produce a full transistor-level schematic of the 68...

Here are some highly optimized versions of VRAM command words: ; Input: d0 = target VRAM address ; Output: d0 = VDP command longword for write to said address VRAM_Write: lsl.l #2,d0 ; Move high bits into (word-swapped) position, accidentally moving everything else addq.w #1,d0 ; Add upper access ty...

FYI, I reuploaded the ROM because, as it turns out, I had an earlier nonworking version layout around which got uploaded instead. My ROM have same goal, but: 1) it has source 2) it has easier bcd implementation AFAIR it has correct bcd implementation I can easily post the source for mine; but since ...

Even BlastEm? Yes, every emulator. Although to be fair, BlastEm does better than most and passes all abcd and nbcd tests, failing only on sbcd: http://i.imgur.com/XwrZi41.png First four rows are the number of errors per instruction; "value" is how many results were wrong, "flags" is how many flags ...

So, I decided to conduct my own investigation into this issue, and did some HW tests, patent investigation, and number crunching; and after doing all that, I discover this thread, in which I confirm my findings that every single emulator does it wrong. In any event, here are my findings, and I hope ...

I am no expert, but I have to confess I don't think they are entirely accurate for the pixel counts per line (numbers for the lines seem fine). Using the best numbers I can find, I come up with the following for H40 mode in NTSC: hsynch ~ 31.55 pixels back porch ~ 30.20 pixels front porch ~ 10.07 pi...

Out of curiosity, are these numbers for the microcode-accurate 68k core or for the old core?